T003 table — Document Type Customizing Table

One row in T003 represents a single document type definition, identified by its two-character code, such as SA for GL postings, KR for vendor invoices, DR for customer invoices, RE for invoice verification, or AB for asset postings. The document type is defined once per client and is available to every company code in that client, unlike most FI customizing which is company-code specific. Each row carries the number range group that determines which number series a document of that type receives, and an authorization group that can be used to restrict posting to certain users. The document type also implicitly governs which account types (GL, customer, vendor, asset, material) are permitted for documents posted with it, enforced at posting time rather than stored as a simple flag list on this table.

Only the fields that are safe to rely on are listed here; the description text lives in a separate language-dependent text table, not on T003 itself.

The join that matters in almost every investigation is the one back from the header table to the document type.

T003 is tiny, typically a few dozen rows per client, so there is no performance concern reading it directly. Restrict on MANDT and BLART and the table returns instantly. The description is not on this table, so a lookup that only hits T003 will show the code but not the label; pull the text table alongside it if the description is needed. Do not use this table to answer questions about posting volume, frequency, or which company codes actually use a given type in practice, those questions are answered from BKPF, not from the customizing entry.

Symptom: a user reports they cannot post with document type RE. Select single row from T003 where MANDT equals the working client and BLART equals RE. Check BRGRU; if populated, compare it against the user's authorization for that group, that is the actual block in most cases. Check NUMKR and then look up the corresponding number range object to confirm the range is not exhausted or expired for the current fiscal year, that is the second most common cause of a hard posting failure that looks like a document type problem.

T003 continues to exist as a customizing table in S/4HANA in essentially the same shape; the document type concept, its number range dependency, and the authorization group control were not restructured by the move to the universal journal. There is no compatibility CDS view standing in front of it because it is configuration, not a transactional table absorbed into ACDOCA. Document type maintenance is still done through the standard IMG activity for document types, not through Fiori app configuration.

The recurring mistake with T003 is treating a client-wide, structural table as if it behaved like transactional or company-code specific master data.

Document type strategy is an FI functional design decision, owned by the FI lead during blueprint and change control afterward, since adding or repurposing a type touches number ranges, authorization design, and downstream reporting. Basis is only involved for the number range object maintenance itself, not for the document type definition.

The language-dependent description lives in the paired text table, not covered here. Document types are maintained through the standard document type configuration transaction, and the associated number ranges through the FI document number range maintenance transaction. Every posted document carries its document type forward into BKPF and, through it, constrains what shows up in BSEG.