SAP Change Documents: CDHDR, CDPOS and the Change Document Framework
SAP Change Documents record who changed a business object, when, and which logged fields changed. CDHDR stores the change-document header and CDPOS stores field-level items keyed by object class/object ID/change number. The framework records only objects/fields configured or coded for change documents, so missing CDHDR/CDPOS entries do not prove that no change occurred; some applications use other audit/history mechanisms.
Practitioner technical guide to SAP Change Documents: CDHDR, CDPOS and the Change Document Framework, with architecture context, a worked example, decision rules, production pitfalls, S/4HANA implications, ownership, and the standard SAP objects used to prove behavior.
Reviewed by an ERPClimb SAP consultant on 20 Sept 2026· 748 words
What it is
The change-document framework is generated around a change-document object. Application code supplies old/new data to generated write logic, which creates a CDHDR header with object class, object ID, user, date/time, transaction context and change number, plus CDPOS items for changed tables/keys/fields and old/new values where supported. Because TABKEY is a serialized technical key and values are stored generically, interpretation requires DDIC knowledge. Some changes are summarized, filtered, archived or represented differently depending on object configuration and field change-document flags.
When to use it
Use change documents when support, audit or a business process needs a standard field-change history for an object that participates in the framework. Use generated change-document objects for custom business data where auditability is required and direct before/after persistence would otherwise be invisible. Do not query CDPOS broadly by field name across production without restrictive object/date filters; it can be very large. For compliance-grade auditing, confirm whether change documents satisfy retention and coverage requirements or whether security audit logs/application-specific logs are also required.
How it fits the stack
CDHDR/CDPOS are cross-application technical tables consumed by 'Environment > Changes' style displays, report tools and audit extractors. They are different from table logging, application logs (BAL), workflow history, IDoc status, and database redo/audit mechanisms. CHANGEDOCUMENT_READ* function modules can read the framework without custom table-key parsing. Archiving can move older change documents out of the online tables, so absence from current CDPOS may be a retention issue rather than proof of no history.
A worked example
A customer credit field appears to have changed unexpectedly. Support captures the business object's change-document class and key, finds the relevant CDHDR entries for the time window, then reads CDPOS for the change number. The history identifies the user, transaction and old/new field values. A second field has no entry; investigation shows that field is not flagged/registered for change-document logging. The team does not conclude that the field was never modified just because CDPOS is silent.
How to choose
- Know the correct change-document object class and business object key before querying history.
- Use date/user/object filters to keep searches selective.
- Use framework APIs or standard change display when possible rather than parsing TABKEY manually.
- For custom objects, decide explicitly which fields require change documents and generate the change-document object accordingly.
- Treat retention/archiving and non-framework application logs as part of the audit design.
Common pitfalls
- Searching CDPOS by field name only and causing expensive broad scans.
- Assuming every database update automatically writes a change document.
- Mis-parsing TABKEY because client/key field lengths changed.
- Using translated display text as the technical field/object identity.
- Treating change documents as an authorization/control mechanism rather than an audit trail.
ECC, S/4HANA and clean core
The classic change-document framework remains widely used in S/4HANA, including by standard business objects and custom on-stack extensions. Fiori apps may surface history through service-specific views, but the backend can still use CDHDR/CDPOS. Clean-core development should use released change-history mechanisms for standard objects rather than directly instrumenting SAP-owned tables.
Whose problem this is
Application/ABAP teams define and write custom change documents; functional owners decide audit-relevant fields. Security/audit teams define retention and evidence requirements. Basis/data-volume management teams support archiving/performance when CDPOS grows very large.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/sap-change-documents-cdhdr-cdposERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.