A P1 alert that fires when an IDoc error stops ecommerce-driven journal entries from posting to the GL.
At a glance
When a commerce order, invoice, or payment flows into SAP S/4HANA Cloud through the IDoc interface and the IDoc errors, the journal entry never posts. The revenue exists economically, the customer has paid, but Finance cannot see it in the General Ledger until the IDoc is reprocessed. This card watches the IDoc inbound and outbound queues, counts entries that failed to post in the last hour, and raises a P1, because every failed IDoc is revenue that is invisible to the GL, missing from the trial balance, and absent from the period close until someone fixes it.
| What it counts | The number of journal-relevant IDocs that failed to post in the last hour, sitting in an error status (typically status 51 inbound application error, 56 IDoc with errors added, or 64 ready to be transferred but stuck). These are postings that should have landed in the Universal Journal but did not. |
| What triggers it | An inbound or outbound IDoc that cannot complete its posting: a missing Sales Document type mapping, a missing partner profile, a currency-conversion failure, a closed posting period, or a master-data gap (customer, material, or GL account not found). |
| Data source | SAP S/4HANA Cloud IDoc status records and the application-log entries from the failed postings (conceptually transactions WE02 / WE05 for IDoc display and BD87 for reprocessing). |
| Company Code scope | IDocs carry the target Company Code. The card flags by Company Code so Finance knows which ledger is missing postings. |
| Real-time vs batch | Real-time, evaluated against a rolling one-hour window. A reprocessed IDoc clears the count on the next poll. |
| Time window | RT (real-time, evaluated continuously) |
| Alert trigger | >0 idoc errors in last 1h |
| Roles | owner, finance, engineering |
Calculation
Calculated automatically from your SAP data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A B2B distributor running SAP S/4HANA Cloud behind a Shopify Plus storefront and an Adobe Commerce wholesale portal. Orders and invoices flow into SAP as IDocs. The card is read at 14:30 on 18 May 26 and reports3. The three failed IDocs in the last hour look like this.
| IDoc | Source | Status | Error | Revenue stuck |
|---|---|---|---|---|
| 0000000045021 | Shopify order | 51 (application error) | Sales Document type missing in mapping | £4,200 |
| 0000000045037 | Adobe invoice | 51 (application error) | Customer business partner not found | £11,800 |
| 0000000045042 | Payment advice | 64 (stuck, not transferred) | Posting period closed for Company Code 2000 | £2,650 |
| Card reading | £18,650 invisible to GL |
- A missing Sales Document type mapping is the most common ecommerce IDoc failure. IDoc 45021 carries a Shopify order whose item maps to a Sales Document type that does not exist in the SAP configuration. The inbound posting cannot decide what kind of document to create, so it errors at status 51. The fix is a configuration change (add the mapping), after which the IDoc reprocesses cleanly. Until then, that £4,200 order is in Shopify but not in the GL.
- Master-data gaps stop the bigger-ticket items. IDoc 45037 fails because the Adobe customer was never created as a business partner in SAP, so the invoice has no payer to post against. This is the expensive failure mode: a new wholesale account places a large first order and the integration has no master-data record to land it. Create the business partner, reprocess, and the £11,800 posts.
- A closed posting period stops everything for that Company Code. IDoc 45042 is a payment advice for Company Code 2000, but period close has already locked the posting period. The IDoc sits at status 64, ready but unable to transfer. The fix is either to open the period briefly for the late posting or to reprocess once the next period is open. This is why the Period Close Past Deadline card and this one often light up together near month-end.
- The sum is what makes this a P1. Three IDocs do not sound serious until you total the stuck revenue: £18,650 that the trial balance does not see. If the queue is not cleared before close, the period understates revenue by that amount and the commerce-to-GL gap widens. The card surfaces the failures within the hour so Engineering and Finance can clear them before they distort the close.
Sibling cards merchants should reference together
A failed IDoc is the acute event; the integration-health story spans several cards. Pair this with these to see the queue depth, the GL impact, and whether the failures are systemic.| Card | Why pair it with Journal Entries Failing to Post |
|---|---|
| Idoc Error Queue Depth (last 24h) | The 24-hour backlog version. This card flags the last hour; the depth card shows whether errors are accumulating faster than they are being cleared. |
| Open / Unposted Journal Entries | Parked and unposted entries that never made it to the GL. A failed IDoc often ends up here as a parked document awaiting correction. |
| Journals by Source Module | Shows the SD / MM / FI split. A drop in the SD share can be the symptom of IDoc-driven sales postings silently failing. |
| Journal Imbalances (debit != credit) | A different integration-logic failure: the document reached SAP but was rejected for being imbalanced. Read both to triangulate where the calling side broke. |
| Period Close Past Deadline (any CompanyCode) | A closed period is a frequent cause of stuck IDocs near month-end. The two cards often correlate. |
| SAP S/4HANA Health Score | The composite roll-up. IDoc error rate is one of the integration-health inputs that pulls the score down. |
Reconciling against SAP
Where to look in S/4HANA Cloud: The closest native equivalents inside the SAP Fiori launchpad are:Monitor IDocs / IDoc List apps for the inbound and outbound queue and per-IDoc status (conceptually transactions WE02 and WE05) Reprocess IDocs for the bulk reprocessing workflow once the root cause is fixed (conceptually transaction BD87) Partner Profiles configuration to confirm a partner profile exists for the message type and partner Application Log for the detailed error text behind a status 51 posting failureDirect link template:
https://my{tenant}.s4hana.cloud.sap/sap/bc/ui2/flp#IDoc-monitor
The IDoc list filtered to error statuses (51, 56, 64) for the last hour should agree with this card to the IDoc. Open each errored IDoc, read the status record and the application log to find the cause (missing mapping, missing partner profile, currency error, closed period), fix the root cause, then reprocess. A reprocessed IDoc moves to a posted status and drops out of the card’s count on the next poll.
Common mistakes when comparing against SAP’s own reports:
- Counting all error IDocs, not just journal-relevant ones. The IDoc list shows every message type. The card counts only postings that should have hit the GL, so a status report covering all message types will show a larger number than this card.
- Mixing inbound and outbound directions. Outbound IDocs (SAP sending to a partner) and inbound IDocs (a partner sending to SAP) both appear in the monitor. The card focuses on the ones whose failure means a journal entry did not post.
- Confusing status 64 with a true error. Status 64 means ready to transfer but not yet processed. If the inbound processing is simply backlogged rather than failed, those IDocs will clear on their own. The card treats persistent 64s as stuck, not transient ones.
| Reason | Direction | Why |
|---|---|---|
| Journal-relevant filter | Card lower | The card counts only postings-relevant IDocs. A monitor view across all message types shows more. |
| One-hour rolling window | Card lower | The card looks at the last hour only. A monitor filtered to a wider date range shows the full backlog, which is what the 24-hour depth card covers. |
| Status-code scope | Either | Whether status 64 (ready, not transferred) is counted as an error or as in-flight affects the number. The card treats persistent 64s as stuck. |
| Reprocessing timing | Either | An IDoc reprocessed between the monitor refresh and the card poll will appear in one but not the other for a moment. |