SAP Change Document Basics: Find and Diagnose Logged Changes

SAP change documents provide an application-level record of selected changes to business data. For operational troubleshooting, the key is to identify the correct object and record before drawing conclusions from a search. The two central tables are CDHDR, which stores change document headers, and CDPOS, which stores individual field-level change records for a logged object.

01How SAP change documents are organized

A change document object defines the data whose changes an application records. When a change is logged, SAP creates a header with context such as the user and time, and corresponding position records for the fields that changed. CDHDR and CDPOS are therefore related parts of a record, not interchangeable logs.

A change document is distinct from a general system log or an application message. It records business-data changes that the relevant application logic is configured to capture. A successful save does not by itself prove that every changed field was included in change-document logging.

02Trace a change from the business object

Start with the application object that a user changed: for example, the business document or master-data record, the approximate time, and the user if known. Confirm the object type and key format used by the application, then use an authorized application display or table-browser tool to search narrowly. The SE16N table-browser reference can help teams align their table inspection with their access controls.

Find the matching header in CDHDR, then check for its field-level records in CDPOS. Compare the changed field and recorded old and new values, where available, with the expected business action. Keep the search constrained by object and time; broad production table scans can create avoidable load and return ambiguous results.

For each finding, capture enough context to reproduce the search: the object type and key, time range, user where relevant, and the header and position records reviewed. Follow your organization’s rules for handling business data when saving screenshots or extracts.

03When expected records are missing

First check whether the application’s change-document object covers the data and fields in question. The object definition and application logic determine what gets recorded. A field that is outside the configured logging scope will not appear as a position record just because its business object was saved.

Next, verify the object key, date and time window, and user selection. Check the business application’s own change display as well as your table search; the application view can help confirm whether the search is using the expected object. If the save used asynchronous update processing, review relevant update records in SM13 update termination monitoring for failures around that time.

Also check your organization’s retention and archiving procedures, along with the access available for archived records. Older changes may require an approved archive retrieval path rather than a current-table search.

04Interpret the evidence carefully

A matching header establishes that a change document was recorded for the identified object and time. Position records provide the field-level detail. Use both parts together when investigating a reported change, and corroborate them with the business document and process context.

A change document does not necessarily explain why a user made a change, whether the business action was authorized, or whether a downstream process completed. For cross-step investigations, establish the sequence of commits and process actions; the SAP logical unit of work overview explains how a logical unit of work frames related updates.

05Operational safeguards

Use read-only access for investigation and follow local authorization procedures. Avoid changing or deleting change-document table records directly. If a record appears inconsistent, preserve the search context and involve the responsible application or platform team to assess configuration, update processing, retention, and application behavior.

For recurring investigations, keep a short runbook with the relevant business object, its change-document object, the approved search route, and the archive contact. Review that runbook after application changes that alter which fields or objects are logged.