Counts journal entries where debits and credits do not balance, a signal that integration logic is broken upstream.
At a glance
SAP S/4HANA Cloud enforces double-entry bookkeeping as a hard rule: a financial document where total debits do not equal total credits cannot post. The Universal Journal will reject it. So in a healthy system this card should read 0 essentially always. When it reads anything above zero, the imbalance is sitting upstream of the GL: a posting request built by an integration, an API caller, or a parked document where the calling side computed the debit and credit sides incorrectly and SAP refused the document. The card is the canary for broken integration logic, because SAP itself will never persist an imbalanced posting.
| What it counts | The number of journal entries or posting requests where the sum of debit lines does not equal the sum of credit lines. In a posted state this should be impossible; the count surfaces rejected, parked, or interface-staged documents whose two sides do not reconcile. |
| What triggers it | An integration or API caller that constructs a posting with mismatched debit and credit lines: a rounding error not absorbed into a clearing line, a tax line omitted, a currency-conversion difference left unbalanced, or a multi-line document where one leg was dropped. |
| Data source | SAP S/4HANA Cloud posting interface and parked-document records, plus rejected posting requests. SAP’s own posted Universal Journal (ACDOCA / BKPF / BSEG) is balanced by construction; the imbalance lives at the staging layer. |
| Company Code scope | Imbalances carry a target Company Code. The card flags by Company Code so Finance and Engineering know which integration path is broken. |
| Real-time vs batch | Real-time. A corrected and reposted document drops out of the count on the next poll. |
| Time window | RT (real-time, evaluated continuously) |
| Alert trigger | >0 |
| 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 retailer running SAP S/4HANA Cloud with a custom middleware that builds FI postings from commerce payment events. The card is read on 06 Mar 26 and reads2. The two imbalanced posting requests look like this.
| Document | Source | Debit total | Credit total | Difference | Cause |
|---|---|---|---|---|---|
| Staged posting A | Payment-event middleware | £1,000.00 | £1,000.03 | £0.03 | Rounding on a 3-way split not absorbed into a clearing line |
| Staged posting B | Payment-event middleware | £4,820.00 | £4,640.00 | £180.00 | Tax line dropped before the document was sent |
| Card reading | 2 |
- SAP never let either document post. Both are rejected at the staging layer. The Universal Journal contains zero imbalanced documents because the hard double-entry rule forbids it. So the
2on the card is not corrupt GL data; it is two posting requests that SAP correctly refused. The job is to fix the calling side and resubmit, not to repair anything inside the ledger. - The three-pence difference is a rounding bug. Staged posting A splits a payment across three GL accounts. The middleware rounded each leg independently and the three rounded legs do not sum back to the gross. The fix is a clearing line that absorbs the sub-penny residue, a standard pattern SAP itself uses. Tiny differences like this are almost always rounding logic that forgot to balance the last line.
- The £180 difference is a dropped tax line. Staged posting B lost its tax line somewhere in the integration before the document reached SAP, so the credit side is short by exactly the tax amount. Large round-ish differences usually mean a whole line was dropped, not a rounding slip. Reading the difference tells you which class of bug you are chasing.
- Persistence is the real signal. A single transient imbalance during a deploy is forgivable. The same imbalance appearing every time a certain payment type flows through means the integration logic is broken for that path and every affected transaction is failing to post. Because the threshold is
>0, the card fires immediately, which is correct: an imbalanced posting means revenue or cash is not reaching the GL until the code is fixed.
Sibling cards merchants should reference together
An imbalance is a code-side failure; the integration-health story spans several cards. Pair this with these to find where the calling side broke.| Card | Why pair it with Journal Imbalances |
|---|---|
| Journal Entries Failing to Post (idoc error queue) | The IDoc-path version of a failed posting. An imbalance is one specific reason an IDoc or API posting is rejected. |
| Idoc Error Queue Depth (last 24h) | The rolling backlog of integration failures. Imbalances often show up here too when they arrive via IDoc. |
| Open / Unposted Journal Entries | A rejected imbalanced document often ends up parked. This card shows the parked-document backlog. |
| Manual Journals (FB50/FB60) as % of Total | Manual postings are a common source of imbalances when a user mistypes a line. High manual share raises imbalance risk. |
| Journals by Source Module | Tells you which source module is generating the imbalanced postings, pointing the fix at the right integration. |
| SAP S/4HANA Health Score | The composite roll-up. Imbalances are a sharp negative input to the GL-integrity component. |
Reconciling against SAP
Where to look in S/4HANA Cloud: The closest native equivalents inside the SAP Fiori launchpad are:Manage Journal Entries filtered to parked and held documents (conceptually transaction FB03 for display, FBV0 for parked-document processing) Application Log / interface monitoring for rejected posting requests from the API or middleware Post General Journal Entries to see the balance validation SAP applies before it will accept a document Embedded Analytics: the journal-line query confirming posted documents always net to zero per documentDirect link template:
https://my{tenant}.s4hana.cloud.sap/sap/bc/ui2/flp#JournalEntry-manage
A key reconciliation point: if you sum debits and credits across any posted document in the Universal Journal, they will always balance, because SAP enforces it. So you will not find this card’s number by querying posted journals. The imbalances live at the staging and rejection layer: parked documents that fail validation, API posting requests returned with a balance error, and middleware logs showing the document SAP refused. Reconcile against the interface monitor and the parked-document list, not against the trial balance.
Common mistakes when comparing against SAP’s own reports:
- Querying posted journals and finding nothing. Posted documents always balance. The imbalance is in the rejected and parked layer. A trial-balance comparison will never reproduce this card.
- Mistaking a balanced-but-wrong document for an imbalance. A document can balance yet post to the wrong account. That is a different problem; this card is strictly about debits not equalling credits.
- Counting both sides of a paired correction. When a user fixes an imbalance by reposting, the original rejection and the new attempt can both appear in logs. The card counts open imbalances, not historical attempts.
| Reason | Direction | Why |
|---|---|---|
| Posted vs staged layer | Card higher | SAP’s posted journals always balance, so a posted-data report shows zero. The card reads the staging and rejection layer where imbalances actually sit. |
| Parked-document inclusion | Either | Whether parked-but-not-yet-posted documents count depends on configuration. The card includes documents SAP rejected for balance. |
| Rounding tolerance | Small | Sub-penny differences that a clearing line should absorb may or may not be counted depending on the tolerance applied. |
| Reposting in flight | Either | A document corrected and reposted between a log refresh and the card poll appears in one but not the other for a moment. |
Known limitations / merchant FAQs
If SAP rejects imbalanced documents, how can this card ever read above zero? Because the imbalance lives upstream of the posted ledger. SAP’s hard double-entry rule means no imbalanced document ever persists in the Universal Journal. What the card counts are the posting requests SAP refused: rejected API calls, parked documents that fail balance validation, and middleware-staged postings whose two sides do not match. The card is reading the failures, not corrupt GL data. A reading above zero means something on the calling side built a bad document, not that SAP let a bad one through. What are the usual causes? A rounding error on a multi-way split where the legs do not sum back to the gross and no clearing line absorbs the residue, a dropped line (most often a tax line) before the document reached SAP, a currency-conversion difference left unbalanced, and a hand-entered manual posting where a user mistyped an amount. Small sub-penny differences point to rounding; large round-ish differences point to a missing line. Why is the threshold zero? Because in a correctly built integration this should never happen. Unlike a queue depth where some background noise is normal, an imbalanced posting is always a defect. There is no acceptable steady-state level. The>0 trigger reflects that any imbalance means transactions are failing to post and the calling code needs fixing.
How do I fix an imbalance?
Find the staged or rejected document (interface monitor or parked-document list), read the difference to classify the bug (small means rounding, large means a dropped line), fix the integration logic or the manual entry, and resubmit. For rounding, add a clearing line that absorbs the residue. Once the corrected document posts, it drops out of the count on the next poll. The fix is always on the calling side, never inside the ledger.
Is a balanced document that posts to the wrong account caught here?
No. This card is strictly about debits not equalling credits. A document that balances perfectly but books to the wrong GL account is a different and harder problem; it posts cleanly and only a reconciliation or review will catch it. Use the source-module and manual-journal cards to spot that class of issue.
Does the card distinguish integration postings from manual ones?
The count is of imbalanced documents regardless of origin, but the breakdown by source module shows whether the imbalance came from an automated integration or a manual entry. A persistent imbalance from one integration path means broken code; an occasional one from manual entry means a user slip. Reading this alongside Manual Journals (FB50/FB60) as % of Total helps separate the two.