> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Journal Entries Failing to Post (idoc error queue), SAP > Journal Entries Failing to Post (idoc error queue) fires when ecommerce-driven postings fail to land in the GL because their IDocs errored in the last hour. Until resolved, the revenue is invisible to Finance. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Nerve Centre](/nerve-centre/connectors#connectors-by-type) > 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 reports `3`. 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** | Four things to notice: 1. **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. 2. **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. 3. **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](/nerve-centre/kpi-cards/sap/period-close-past-deadline-any-companycode) card and this one often light up together near month-end. 4. **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)](/nerve-centre/kpi-cards/sap/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](/nerve-centre/kpi-cards/sap/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](/nerve-centre/kpi-cards/sap/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)](/nerve-centre/kpi-cards/sap/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)](/nerve-centre/kpi-cards/sap/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](/nerve-centre/kpi-cards/sap/sap-s4hana-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 failure Direct 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. **Why our number may differ from SAP's reports:** | 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. | ## Known limitations / merchant FAQs **Why is a failed IDoc a P1 alert?** Because the revenue is invisible to the GL until the IDoc is fixed. The customer has paid, the order exists in the commerce platform, but the journal entry never posted, so the trial balance, the period close, and every revenue card understate by the stuck amount. If the queue is not cleared before close, the books are wrong. An IDoc failure is a direct, quantifiable hole in the financials, which is why it sits at the top tier. **What are the most common causes of IDoc posting failures?** A missing Sales Document type mapping (the inbound posting cannot decide what document to create), a missing business partner (a new commerce customer was never created in SAP), a currency-conversion error (an FX rate is missing for the document date), and a closed posting period (the period is locked for close). Master-data gaps and configuration gaps cover the large majority. Currency and period issues cluster near month-end. **What do status codes 51, 56, and 64 mean?** Status 51 is an inbound application error: the IDoc reached the posting step and the application rejected it. Status 56 is an IDoc added with errors, usually a structural or partner-profile problem before posting even starts. Status 64 is ready to be transferred to the application but not yet processed; persistent 64s mean the inbound processing is stuck rather than backlogged. The card focuses on the statuses that mean a journal entry did not post. **How do I clear the alert?** Fix the root cause, then reprocess the IDoc. For a missing mapping or partner profile, make the configuration or master-data change and reprocess (conceptually transaction BD87). For a closed period, open the period briefly or wait for the next open period. Once the IDoc posts, it drops out of the card's count on the next connector poll. The card reflects live queue state; there is no manual acknowledgement. **Does the card cover outbound IDocs too?** The headline concern is inbound postings that should have hit the GL, because those represent revenue invisible to Finance. Outbound IDocs (SAP sending data to a partner) are a different failure mode. The card prioritises the journal-relevant inbound failures; whether outbound errors are surfaced depends on the connector configuration. **Why does this card often fire alongside the Period Close card?** Because a closed posting period is one of the most common reasons an IDoc cannot post near month-end. When Finance locks the period for close, late-arriving commerce postings cannot land and queue up at status 64. Reading [Period Close Past Deadline](/nerve-centre/kpi-cards/sap/period-close-past-deadline-any-companycode) alongside this card tells you whether the IDoc backlog is a code problem or simply a period-timing problem that will clear when the next period opens. **Is this the same as the 24-hour queue depth card?** No. This card flags errors in the last hour, so it is the acute, act-now signal. The [Idoc Error Queue Depth (last 24h)](/nerve-centre/kpi-cards/sap/idoc-error-queue-depth-last-24h) card shows the rolling backlog and tells you whether errors are accumulating faster than the team is clearing them. Read this one to react and that one to spot a trend. *** ### Tracked live in Vortex IQ Nerve Centre *Journal Entries Failing to Post (idoc error queue)* is one of hundreds of KPI pulses Vortex IQ tracks across SAP and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.