BALHDR table — Application Log Header Table

One row in BALHDR represents a single application log instance opened by a program or process through the log creation function of the SBAL framework. It carries the classification of the log (object and subobject, maintained in customizing for each application area), an optional external number used to tie the log to a business document or run, the creation timestamp, the user, the calling program and transaction code, and a planned deletion date used by log reorganization. The row is essentially an index card: it tells a reader that a log exists, who created it, when, and under what business classification, but the individual messages inside that log (severity, message class, message number, free text, variables) are not part of this table. Those are stored serialized under the same internal log handle in BALDAT and only decoded on display.

BALHDR is client-dependent, always restrict by MANDT implicitly through the transaction. Never select on ALDATE alone on a system with heavy interface or batch logging; always add OBJECT, and SUBOBJECT if known, first. EXTNUMBER lookups feel natural for consultants chasing a specific document but are only as selective as the calling program made them; many programs leave it blank, so a search that returns zero rows on EXTNUMBER does not prove the log was never created. Reading message content requires going through the log display function, not a direct SE16 join to BALDAT, because the payload there is a serialized cluster, not flat columns.

Symptom: an interface run reportedly failed but nobody can find a log for it. Select BALHDR restricted to the OBJECT and SUBOBJECT owned by that interface, ALDATE equal to the run date, and ALUSER equal to the technical or batch user that executes the job. If a row exists, take its LOGNUMBER and read the log through the display transaction or the read function module to decode BALDAT. If no row exists at all, either the program never called the log-create step on that path, or a reorganization job already deleted it based on ALDATE_DEL.

BALHDR is unchanged in role and structure on S/4HANA. The application log framework is a basis technical service and was not part of the Simple Finance or logistics simplification scope, so the header and its companion data table continue to be written and read the same way, through the same log creation, display and reorganization transactions. No CDS compatibility view is required here because BALHDR is not a business data table subject to code pushdown or replacement logic.

A missing or unreadable log is first a question for basis, since log volume, reorganization scheduling and archiving policy for this table are basis-owned. Whether a specific process should have logged something at all, and what OBJECT and SUBOBJECT it should appear under, is owned by the functional or development team responsible for the program that calls the log creation step.

BALDAT holds the serialized message content for each LOGNUMBER and is always read together with BALHDR through the log display or read function, never joined directly in a report. The log lifecycle is driven from the display transaction, the object/subobject customizing transaction, and the reorganization transaction that enforces ALDATE_DEL. Background jobs recorded in TBTCO and TBTCP are frequently the actual trigger that creates application log entries during a job step, which is why job tables are the first place to check when a log's creating context is unclear.