CDHDR table — Change Document Header
CDHDR stores the header of SAP change documents created by the change-document framework. A header identifies the change-document object and business object key plus change number, user, date, time, and transaction context. It proves that the framework recorded a change event, but application coverage depends on whether that object and field are configured to write change documents.
A consultant-focused reference for CDHDR covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 706 words
What it stores
CDHDR stores one header per recorded business-object change, identifying who changed what, when and through which transaction. Each row must be interpreted using the complete technical key and the application process that writes it. A consultant should first establish whether the row represents current state, a dated master-data slice, a document item, a history event, an index entry or a compatibility representation. Organizational levels, validity dates, fiscal years, ledgers, languages, statuses and sequence numbers are part of the grain whenever those dimensions exist. The table should be read as evidence of application behavior, not as an isolated spreadsheet. Confirm the owning business object and configuration before deciding that a value is wrong.
Key fields
OBJECTCLAS, OBJECTID and CHANGENR uniquely scope a change-document event in its client context. UDATE, UTIME, USERNAME and TCODE describe the recorded change context rather than the current state of a business record.
- OBJECTCLAS — change-document object class.
- OBJECTID — business object key in the change-document framework.
- CHANGENR — change number linking to CDPOS.
- USERNAME — user who made the change.
- UDATE/UTIME — change date and time.
- TCODE — transaction context where recorded.
How it joins the data model
Join CDHDR to CDPOS using the complete change-document identity; one header can have many changed field items. To interpret TABKEY or individual old/new values, inspect the relevant change-document object configuration and table metadata.
- OBJECTCLAS, OBJECTID and CHANGENR to CDPOS
- OBJECTCLAS to change-document object configuration
- USERNAME to user master data where authorized
How to read it safely
For a disputed master-data change, first find the correct object-class and business key, then inspect the user/time and the individual CDPOS field entries. A mass update may produce many CDPOS rows under one event; do not count changed fields as separate user actions.
How to prove it in the data
Take one reproducible example from the relevant SAP screen, report or application log. Record its full displayed key, organizational context, key date, language and status. Locate the matching CDHDR row using those values, then follow the documented parent and child joins without dropping key components. Compare the result using the same key date and ledger. When values differ, test for leading-zero conversion, multiple validity slices, inactive history, parallel ledgers, fiscal-year boundaries, archived data and asynchronous replication. Save the read-only evidence before escalating. If the row is wrong, reproduce the maintenance path in a non-production system and route the fix to the application owner rather than changing the table.
ECC vs S/4HANA
CDHDR remains the standard change-document header in S/4HANA. Fiori apps and CDS-based history views may surface the same information differently, but absence of CDHDR/CDPOS entries does not prove that no business change occurred if an application uses another logging mechanism.
Common pitfalls
- Selecting by one convenient identifier and silently mixing organizational units, years, ledgers, languages or validity periods.
- Joining on a partial key or descriptive value and creating duplicates that appear to be legitimate business rows.
- Ignoring inactive, deletion, reversal or status indicators and reporting retained history as current state.
- Assuming this table is authoritative without checking S/4HANA simplification, Business Partner synchronization, Universal Journal, MATDOC, CDS views or an external cloud source.
- Treating a missing row as proof that an event never occurred even though logging, replication, authorization and archiving scope can differ.
- Updating table rows directly instead of correcting data through the supported transaction, app, API or migration process.
Whose problem this is
The business data owner decides whether a change was permitted. Application support validates change-document instrumentation; security/audit investigates proven access or approval anomalies.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/cdhdrERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.