The rolling 24-hour count of errored IDocs, the headline gauge of ecommerce-to-SAP integration health.
At a glance
Every commerce order, invoice, and payment that flows into SAP S/4HANA Cloud through the IDoc interface either posts cleanly or lands in an error queue. This card counts the IDocs stuck in error status (51 application error, 56 IDoc with errors, 64 ready but stuck) across the last 24 hours. A low and stable number is healthy integration. A rising number means errors are being created faster than the team is clearing them, which is the leading indicator that your storefront and your General Ledger are drifting apart. The typical ecommerce-integration failure modes are a missing Sales Document type, a missing partner profile, and a currency-conversion error.
| What it counts | The number of IDocs in error status (51, 56, or 64) over the rolling 24-hour window. This is the queue depth, not a per-event flag, so it tells you the size of the backlog rather than the latest single failure. |
| What drives it up | Sustained inbound failures: a Sales Document type missing from the mapping, a partner profile missing for a message type, a currency conversion that cannot find an FX rate, or master-data gaps where a commerce customer or material has no SAP record. |
| Data source | SAP S/4HANA Cloud IDoc status records (conceptually visible in transactions WE02 / WE05) aggregated over 24 hours, with reprocessing handled in BD87. |
| Company Code scope | IDocs carry their target Company Code. The depth can be sliced by Company Code to show which ledger is accumulating the most failures. |
| Real-time vs batch | Rolling real-time aggregate. The depth recalculates on every poll, so cleared IDocs drop out and new failures appear within a poll cycle. |
| Time window | 24H (rolling 24-hour window) |
| Alert trigger | >10 |
| 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 mid-market retailer running SAP S/4HANA Cloud behind a Shopify Plus storefront. Orders, invoices, and payment advices flow in as IDocs roughly every few minutes through the day. The card is read at 17:00 on 20 Apr 26 and reads14, which is over the >10 alert threshold. The 24-hour backlog breaks down like this.
| Error status | Count | Dominant cause | Typical fix |
|---|---|---|---|
| 51 (application error) | 8 | Sales Document type missing in mapping | Add the document-type mapping, reprocess |
| 51 (application error) | 3 | Business partner not found | Create the missing customer, reprocess |
| 64 (ready, not transferred) | 2 | Posting period locked for Company Code 2000 | Open period or wait for next period |
| 56 (IDoc with errors) | 1 | Partner profile missing for message type | Add the partner profile, reprocess |
| Card reading | 14 |
- The depth is over threshold because of one config gap. Eight of the fourteen errors share a single root cause: a new product line whose item maps to a Sales Document type that was never configured. One fix clears more than half the queue. The card reads
14, but the work is closer to four distinct problems, not fourteen. The depth tells you the size of the backlog; the breakdown tells you how concentrated it is. - A rising depth is worse than a high depth. A steady
14that the team clears every afternoon is annoying but stable. A14this hour,22next hour,35after that is a runaway: errors are being created faster than they are being cleared, and the gap between Shopify and the GL is widening by the minute. Watch the trendline, not just the level. - Status 64 is the period-close tell. The two stuck-but-ready IDocs are payment advices for a Company Code whose period is locked for close. They are not broken; they are waiting. Near month-end this status climbs for benign reasons and clears when the next period opens. Separating 64 from 51 stops Finance chasing code problems that are really timing problems.
- The depth is the leading indicator for the revenue gap. Every IDoc in this queue is a commerce transaction that has not reached the GL. A persistent backlog directly feeds the commerce-to-GL revenue gap and the missing-sales-document count. When this card climbs, expect Revenue Gap vs Commerce to widen a day or two later. Clearing the queue is the cheapest way to close that gap.
Sibling cards merchants should reference together
Queue depth is the trend gauge; the integration story spans the acute alert and the downstream financial impact. Pair this with these.| Card | Why pair it with Idoc Error Queue Depth |
|---|---|
| Journal Entries Failing to Post (idoc error queue) | The acute last-hour alert. This depth card shows the rolling backlog; that card fires the moment a journal-relevant IDoc fails. |
| Commerce Orders without S/4HANA Cloud Sales Document | The direct consequence: orders that never became SAP documents because their IDoc failed. |
| Revenue Gap vs Commerce | A persistent error queue widens this gap. The depth card is the leading indicator. |
| Journals by Source Module | A falling SD share can signal that sales IDocs are quietly failing rather than posting. |
| Period Close Past Deadline (any CompanyCode) | A locked period drives status-64 depth near month-end. Read together to separate timing from code. |
| SAP S/4HANA Health Score | The composite roll-up. IDoc queue depth is one of the integration-health inputs. |
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 filtered to error statuses 51, 56, 64 over the last 24 hours (conceptually transactions WE02 and WE05) Reprocess IDocs for clearing the backlog once root causes are fixed (conceptually transaction BD87) Partner Profiles to confirm a profile exists for every active message type Application Log for the detail behind each 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 and a 24-hour posting-date range should match this card to the IDoc. To act on the depth, sort the list by error reason rather than by IDoc number; you will usually find a small number of root causes accounting for most of the queue. Fix the configuration or master-data gap, reprocess the affected IDocs in bulk, and watch the depth fall on the next poll.
Common mistakes when comparing against SAP’s own reports:
- Counting every message type, not just commerce-relevant ones. The IDoc monitor shows all traffic. The card focuses on the commerce-integration message types whose failure matters to the GL, so an all-types count will be higher.
- Including transient status 64 as a hard error. Status 64 means ready but not yet processed. Some of these clear on their own as inbound processing catches up. The card distinguishes persistent stuck IDocs from a brief backlog.
- Comparing different windows. A monitor view set to a wider date range counts older errors that fall outside the rolling 24 hours. Always match the window when reconciling.
| Reason | Direction | Why |
|---|---|---|
| Commerce-relevant message-type filter | Card lower | The card scopes to integration message types that matter to the GL. An all-types monitor view counts more. |
| 24-hour rolling window | Card lower | The card looks at the last 24 hours. A monitor filtered to a longer range counts older errors too. |
| Status-64 treatment | Either | Whether ready-but-stuck IDocs count as errors affects the depth. The card treats persistent 64s as backlog. |
| Reprocessing in flight | Either | IDocs reprocessed between the monitor refresh and the card poll appear in one but not the other for a moment. |
Known limitations / merchant FAQs
What does the depth actually tell me that the per-event alert does not? Direction and concentration. The per-event alert tells you an IDoc just failed; the depth tells you how big the backlog is and, when read over time, whether it is growing or shrinking. A flat depth that the team clears daily is manageable. A climbing depth means errors are outpacing fixes, which is the real warning sign. Always read the depth as a trend, not a single number. Why is the threshold set at more than ten? A small number of errored IDocs is normal background noise in any busy integration: a one-off master-data gap, a transient currency-rate miss, a single late posting against a closing period. The>10 trigger separates that routine churn from a genuine accumulation that needs Engineering attention. If you run a very high transaction volume, the underlying breakdown by root cause is more useful than the raw count.
What do statuses 51, 56, and 64 mean?
Status 51 is an inbound application error: the IDoc reached posting and was rejected, usually a mapping or master-data problem. Status 56 is an IDoc added with errors, typically a structural or partner-profile issue before posting. Status 64 is ready to transfer but not yet processed; persistent 64s mean inbound processing is stuck. The card counts all three but the breakdown matters because 64 is often benign and timing-related.
The depth jumped overnight. What happened?
Usually one config or master-data gap that affects many transactions. A new product line with an unmapped Sales Document type, a new wholesale customer with no business partner, or a missing FX rate for the day will fail every affected IDoc until fixed. Sort the queue by error reason; you will almost always find a handful of root causes behind a large depth, and one fix clears many entries.
Does a high depth mean revenue is lost?
No, it means revenue is delayed and invisible. The transactions exist in the commerce platform and the customers have paid; they simply have not posted to the GL yet. Once the IDocs reprocess, the revenue lands. The risk is that a backlog persists across period close, in which case the period understates revenue until the queue clears. Clearing the queue restores the numbers.
How does this relate to the revenue gap?
Directly. Every IDoc in the queue is a commerce transaction missing from the GL, so a persistent depth feeds straight into the commerce-to-GL Revenue Gap vs Commerce. The depth card is the leading indicator: when it climbs, the gap widens a day or two later. The cheapest way to shrink the gap is often to keep this queue near zero.
Can I see which Company Code is worst?
Yes. IDocs carry their target Company Code, so the depth can be sliced by Company Code to show which ledger is accumulating the most failures. This is useful when one entity has a configuration or master-data gap that the others do not, because it points the fix at the right place.