ACC_DOCUMENT message type — ACC_DOCUMENT IDoc for accounting document posting
ACC_DOCUMENT is the IDoc message type used to post a complete accounting document (header, line items, currency amounts, tax) from a sending system into an SAP FI/CO ledger. It mirrors the structures behind the accounting-document-post interface. It is almost always inbound to the system that owns the general ledger, arriving from a feeder application, an industry solution, or an integration flow built on SAP BTP.
This page covers what ACC_DOCUMENT actually transports, its main segments, the partner profile and process code setup required for it to post, and the order in which to check a stuck or failed IDoc of this type. It also flags the specific ways this message type misleads whoever is troubleshooting it, particularly around multi-line documents and duplicate reposting.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 1,145 words
What it carries
ACC_DOCUMENT carries one accounting document per IDoc: everything needed to create a posted FI or CO document in the receiving system, structured the same way the accounting-document-post interface expects it. The direction is inbound to the SAP system that owns the ledger. The sender is typically a feeder application, an industry component, or an integration flow running on SAP BTP Integration Suite that has already assembled a business event into postable accounting data. It is a fire-and-forget posting mechanism: the sender does not get an inline document number back in the same exchange. Confirmation of success or failure comes back as the IDoc status record, and, in some landscapes, as a separate acknowledgement or a status IDoc sent back to the originator. It is not used to query or reverse a document; reversal is a separate posting.
Segments
The IDoc structure follows the accounting-interface data model closely, so each segment maps to a recognizable business block rather than being generic. The header segment carries the document-level attributes, one line-item segment repeats per posting line, and separate segments hold currency and tax detail so that one physical document can carry several currency views and several tax lines without duplicating the whole line item.
- Header segment: company code, document date, posting date, document type, reference document number, header text, currency key
- Line item segment: repeats once per posting line, carries GL account or reconciliation account, cost center or other account assignment, debit or credit indicator, amount in local currency, item text
- Currency segment: parallel currency amounts tied back to a specific line item, used when the document carries more than one currency view
- Tax segment: tax code, tax base amount, tax amount per line where tax applies
- Withholding tax segment: withholding tax code and base where the document requires it
Configuration
On the receiving side, the partner profile must have an inbound parameter for message type ACC_DOCUMENT with a process code that points to the inbound function module responsible for calling the accounting-document-post logic, and processing set to trigger immediately rather than only via a background collection run unless that is the intended pattern. The port is usually an internal RFC or tRFC port when the sender is another SAP system, or a port fed by an adapter (IDoc adapter on Integration Suite, or a middleware) when the sender is external. There is normally no output-determination step involved, because this message type does not originate from a master-data or sales-document output condition; it is generated programmatically by the sending application or assembled directly by an integration flow. What does need checking is the partner number and partner type used by the sender, since a mismatch there causes the IDoc to fail before it reaches any FI logic at all.
What to inspect when it fails
Work from the IDoc status backward into the application, not the other way round.
- WE02 or WE05: open the IDoc, read the status record text in full before assuming anything, since the header status hides which line failed
- Status 51: the posting was rejected by the accounting interface; the message class and number in the status record point to the real FI or CO validation error, not a technical one
- Status 64 or 56: the IDoc never reached the application; check the partner profile inbound parameter and process code assignment in WE20
- WE19: replay the IDoc in test mode against the same data to isolate whether the failure is data-driven or configuration-driven before touching production data
- SM58: if the transport is RFC or qRFC based, check for entries stuck in the queue rather than a status showing at all
- If the IDoc originates from a BTP integration flow, check the integration flow's message monitoring first, since a mapping or content-modifier error there can produce an IDoc that is technically valid but semantically wrong before it ever shows a status 51
Whose problem this is
FI owns the diagnosis once the status record points to a posting-level rejection: account assignment, tax code, period status, document type. Basis owns the port, the partner profile plumbing, and any RFC or queue that is stuck before the application ever sees the IDoc. If the source is a BTP integration flow, the integration team owns the mapping and content before handoff, and their message log should be pulled before escalating to FI, since a mapping defect there can look identical to a genuine accounting error.
Common pitfalls
This message type is easy to misread because the header status does not tell the whole story of a multi-line document.
Reprocessing the IDoc from BD87 immediately after a status 51, without reading the message text in the status record, is the standard reflex. It usually fails again for the same reason and burns a cycle, or worse, it succeeds after someone quietly opened a closed posting period or unlocked a cost center just to make the error disappear, without addressing why the sending system produced a document against a closed period in the first place. Deleting and recreating the partner profile is another common overreaction when the actual fault is a locked account assignment object or a document type not allowed for that company code.
- A single bad line item stops the entire document from posting, but the failing line is not identified in the header status; it has to be found inside the status record message or the application log
- Status 53 means the document posted, but the resulting FI document number is not printed on the IDoc itself in an obvious place; it has to be traced through the document flow or the application log linked to that IDoc
- The status-record error text is often a generic accounting-interface message even when the true cause is a specific FI validation, such as a tax code not valid for the company code or a reconciliation account not open for direct posting
- Currency-segment rounding mismatches look like an interface mapping bug but are usually a genuine rounding difference between the sending system's currency conversion and the receiving system's
- Reprocessing an IDoc after fixing the underlying master data can create a duplicate posting if the original document actually posted partially before failing, so the document flow should be checked before any resend
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-idoc/acc-documentERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.