Open (Unposted) Journal Entries, SAP

Open (Unposted) Journal Entries, the count of accounting documents stuck before posting in S/4HANA Cloud, often from an IDoc import failure. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Executive Overview

AccountingDocuments stuck in the error queue. Common cause: IDoc IMPORT failure on a Sales Document type from the ecom integration.

At a glance

The count of accounting documents that have been created or parked in S/4HANA Cloud but have not yet posted to the Universal Journal. These are entries stuck before they hit the GL: parked documents awaiting approval, held documents, and, most importantly for commerce shops, documents that failed to post because an inbound IDoc errored. Every unposted entry is revenue, cost, or cash that the ledger does not yet recognise, and during period close it is the gap between what happened and what the books show.

What it counts	The number of accounting documents in a created, parked, or held state that have not yet posted. Parked documents live in the parked-document tables (VBKPF / VBSEGD heritage, surfaced via the Manage Journal Entries Fiori app) and are not yet in ACDOCA. The card also counts entries failing to post from the inbound IDoc queue, which never reach the parked state because the import itself errored.
Most common cause	An IDoc IMPORT failure on a Sales Document or billing document inbound from the ecommerce integration. When the ecom platform pushes an order or invoice via IDoc and a mapping, master-data, or configuration error blocks it, the document sits in the error queue (monitored via transaction WE02 / WE05 or the Application Interface Framework) and never posts.
Reading the value	A small standing count is normal during the working day as parked entries await approval. A rising count, or a count that does not clear overnight, signals a systemic problem: a broken IDoc mapping, missing master data on a business partner, or a closed posting period rejecting documents.
Currency	Count metric, currency-agnostic. The card reports a number of documents, not a value. For the value at risk, pair with the journal-imbalance and IDoc-queue cards.
Company Code scope	Respects the dashboard Company Code filter. By default counts unposted entries across every Company Code visible to the connected SAP business user / API role.
Time window	RT (real-time queue depth)
Alert trigger	>50
Roles	owner, finance

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 UK enterprise commerce group on SAP S/4HANA Cloud Public Edition, two Company Codes, taking orders from a Shopify Plus DTC store and a BigCommerce B2B portal via IDoc. Live snapshot at 03 May 26.

Source of unposted entry	Count	Typical cause
Parked, awaiting approval	14	Manual journals over the approval-required value, in workflow
IDoc import failure, Sales Document inbound	38	Ship-to business partner not yet created in SAP for new ecom customers
IDoc import failure, billing document inbound	11	Tax code on the ecom order not mapped to an SAP tax code
Held documents	6	Users saved and did not complete
Open (Unposted) Journal Entries (this card)	69

Four things to notice:

1. The count is 69, above the 50 alert threshold. The gauge fires. The bulk, 49 of 69, is IDoc import failures from the ecom integration, which is the single most common cause this card exists to catch.
2. The 38 Sales Document failures share one root cause. New ecommerce customers are placing orders before their business partner record exists in SAP. The fix is upstream: ensure the customer is created as an SAP business partner before the order IDoc arrives, or enable auto-creation. This is the same gap surfaced by the “ecom customers absent from SAP business partner” card.
3. The 11 billing failures are a tax-mapping problem. An ecom tax code with no SAP equivalent blocks the billing IDoc. One configuration fix in the tax-code mapping clears all eleven and prevents recurrence.
4. The 14 parked entries are healthy. They are manual journals waiting for approval in the normal workflow and will post once approved. The card counts them, but they are not the problem. The signal is in the IDoc-failure slice, so always drill by source.

T-codes / Fiori apps for drilling in:

• WE02 / WE05: IDoc list and monitoring (find and reprocess failed inbound IDocs).
• BD87: reprocess IDocs in error status.
• Manage Journal Entries Fiori app: parked and held documents awaiting posting.
• FBV0 / FB50: post or complete a parked manual journal.
• Application Interface Framework (AIF) monitor: inbound interface error queue, where used.

Sibling cards merchants should reference together

Open (Unposted) Journal Entries is a data-integrity and close-readiness signal. Pair it with the IDoc, journal, and close cards to find the root cause and the value at risk.

Card	Why pair it with Open (Unposted) Journal Entries
IDoc Error Queue Depth (last 24h)	The upstream cause for most unposted entries in a commerce shop.
Journal Entries Failing to Post (IDoc error queue)	The journal-specific slice of the IDoc failure queue.
Journal Imbalances (Debit/Credit)	An unbalanced entry will not post; this names the imbalanced ones.
Manual Journals (FB50/FB60) as-of total	The parked manual-journal slice waiting on approval.
Period Close Status (by CompanyCode)	Unposted entries block a clean close; this shows which entity is held up.
Ecom Orders Missing Matching SAP Billing Document	The downstream symptom: orders that never billed because their entry never posted.
SAP S/4HANA Health Score	This count is a component of the composite health score.

Reconciling against SAP

Where to look in S/4HANA Cloud:

The closest native equivalents inside the SAP Fiori launchpad are:

Manage Journal Entries Fiori app filtered to parked and held documents IDoc List transactions WE02 / WE05 filtered to inbound, error status Reprocess IDocs transaction BD87 for documents in error Application Interface Framework monitor for the inbound interface error queue Embedded Analytics: the parked-document and IDoc-status CDS views in your release

Direct link template: https://my{tenant}.s4hana.cloud.sap/sap/bc/ui2/flp#JournalEntry-manage

To reproduce the card, count parked and held accounting documents in the Manage Journal Entries app, then add inbound IDocs in error status from WE05 that target an accounting or billing document. The combined count should match the card when run at the same moment and Company Code scope.

Common mistakes when comparing against SAP’s own reports:

• Parked vs error vs held. These are distinct states in SAP. A report filtered to only parked documents misses the IDoc-error slice, which is usually the larger and more urgent group.
• IDoc status codes. WE05 shows many status codes. Only error statuses (51 and similar) represent genuinely stuck documents; status 64 means ready to process, not failed. Filter to error statuses only.
• Already-reprocessed IDocs. An IDoc reprocessed successfully changes status. A report run before a BD87 reprocessing batch overcounts. Match the timestamp.

Why our number may differ:

Reason	Direction	Why
State definition	Either	The card combines parked, held, and IDoc-error documents. A report filtered to a single state shows a smaller count.
IDoc status filter	Either	Counting all IDoc statuses rather than error statuses only overstates the queue. The card counts genuinely stuck documents.
Snapshot timing	Either	Reprocessing or approval activity between the card snapshot and a manual report shifts the count. Match the timestamp.
Company Code scope	Either	The card respects the dashboard filter. A WE05 run without a Company Code restriction counts entries the dashboard filter would exclude.
Interface framework vs raw IDoc	Small	Tenants using AIF route some interfaces through AIF rather than raw IDocs. The card reads both where configured; a WE05-only manual check misses the AIF queue.

Cross-connector reconciliation:

This card has no direct commerce-platform counterpart, but it is fundamentally a commerce-integration health metric. The orders sitting in the ecom platform that have no posted SAP document are the mirror image of this count. Pair with the Ecom Orders Missing Matching SAP Billing Document card to see the commerce-side symptom of the same failures.

Known limitations / merchant FAQs

Why is the most common cause an IDoc failure on a Sales Document? Because commerce integrations push orders into SAP as inbound IDocs, and the most fragile dependency is master data. When a new ecommerce customer orders before their business partner record exists in SAP, the Sales Document IDoc has nowhere to land and errors. Tax-code mismatches, missing material masters, and closed posting periods are the next most common causes. All of them block the import before the document ever reaches the parked state.

Is a non-zero count always a problem? No. A handful of parked manual journals awaiting approval is normal during the working day and clears as approvers act. The signal is the IDoc-error slice and any count that does not drain overnight. Always drill by source: parked-awaiting-approval is healthy, IDoc-error is not. The card’s value is in catching the failure queue before period close.

Does an unposted entry affect the GL revenue and cash cards? Yes, by omission. An entry that has not posted is not in the Universal Journal, so it is not in Revenue Booked into GL, Cash Collected, or any balance card. A large unposted queue means the financial headline cards are understated by the value of those stuck documents until they post. This is why the count spikes are a close-readiness red flag.

How do I clear the queue? Fix the root cause, then reprocess. For IDoc errors, identify the failing reason in WE02, fix the upstream data (create the missing business partner, map the tax code, open the period), then reprocess with BD87. For parked manual journals, route them through approval. Clearing the symptom without fixing the cause just refills the queue on the next batch.

Does the card distinguish manual journals from automated postings? It counts both but the drill-down separates them by source. Manual parked journals (FB50, FB60) are usually a workflow-approval matter. Automated postings failing via IDoc are an integration matter. The two need different owners: Finance for approvals, the integration team for IDoc mappings.

Can I change the alert threshold? Yes. The default fires above 50. Tune it per workspace in the Alert Rules tab. High-volume commerce shops with large daily IDoc traffic may sit at a higher healthy baseline; low-volume operations should set it lower so any stuck document is caught early.

What happens to these entries at period close? They block a clean close. SAP will not let you close a posting period cleanly while documents that belong to it are unposted, and any IDoc-error documents represent transactions missing from the period’s results. This card is one of the components feeding the SAP S/4HANA Health Score and is a direct input to close readiness; clear it before the close deadline.

---

Tracked live in Vortex IQ Nerve Centre

Open (Unposted) Journal Entries 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 or book a demo to see this metric running on your own data.