Balance in Transaction Currency Error at Posting

An AP clerk reports that an invoice will not save: the system throws an error naming a currency and a small non-zero amount, even though the totals on the invoice look correct. An AR clerk clearing a customer payment against an open item gets the same message and cannot understand why the document balances on screen but the system disagrees. A batch monitoring team reports that a batch of EDI or interface-driven invoices is failing overnight with the identical error, always for foreign currency documents, never for local currency ones. In all three cases the complaint sounds like a system bug because the header total and the sum of visible line items appear to match; the mismatch is happening in a currency the user is not looking at, typically because the document uses more than one currency internally.

Ranked by how often each actually turns out to be the cause in practice.

Work from the error message outward rather than guessing at configuration first.

Pull the document in simulation in FB03 or during entry and list every line's amount in document currency, grouped by currency, and sum each group independently rather than trusting the header total. For clearing cases, pull the open items in FBL1N or FBL5N with their posted exchange rate and compare against the rate used on the clearing document from OB08. For interface postings, pull the source IDoc or interface payload and compare line-level amounts and rounding against what FI received.

For manual entry errors, the fix is data correction at the point of entry: let the system calculate the balancing line amount instead of keying every line, then re-simulate before posting. For document splitting rounding, the fix is configuration in the splitting rule: assign or correct the rounding difference item category on the affected document type or business transaction, which is a transport-based change owned by the FI configuration team. For clearing-related exchange rate mismatches, check the automatic account determination for exchange rate differences in OBA1; if the accounts are missing or the posting keys are wrong, that is a configuration fix requiring transport, while a one-off document with a genuine small residual can be cleared with a manually posted exchange rate difference line as a data action. For interface rounding, the durable fix is a development change so the source system rounds once at document level, not per line; adjusting the tolerance group is a legitimate but narrower config change and should only cover the actual rounding scale seen, not be widened arbitrarily. For substitution or user exit issues, the rule or exit logic itself needs correcting and transporting.

The reflex fix is to widen the tolerance group in OBA4 until the document posts, or to add a manual plug line for the difference just to get the invoice through. Both mask the underlying currency mismatch instead of resolving it. A widened tolerance silently swallows larger discrepancies on every future document for that user or company code, which becomes a currency translation and audit problem later. A manual plug line creates a suspense posting with no economic meaning that someone has to identify and clean up downstream, and it does nothing to stop the same interface or splitting configuration producing the same error on the next document.

Manual entry mistakes belong to the AP or AR clerk and the transaction is corrected at entry, no ticket needed. Document splitting rounding and exchange rate account determination are owned by FI configuration. Interface rounding is owned jointly by the interface development team and FI; the handover note should carry the document number, company code, transaction currency and imbalance amount, and the exchange rates involved on both sides of the posting.