Open Item Clearing Blocked by Tolerance Difference

An AR or AP clerk is trying to clear an incoming payment against an open invoice, or net a credit memo against a debit, in F-28, F-32, F-44 or a manual clearing transaction, and the system stops the posting with a message that the difference is too large to post automatically, or refuses to let the line go green. The clerk sees a small leftover amount, sometimes a few cents, sometimes a meaningful sum, that will not net off no matter how the items are selected. The business description is usually 'the payment matches the invoice but the system will not let me clear it' or 'the customer paid 4.50 short and I cannot close the invoice'. It gets escalated when the clerk tries increasing the tolerance themselves and finds no authorization, or when automatic clearing (F.13) silently skips items that manual clearing then also rejects.

Pull the open item and the attempted clearing amount from FBL5N or FBL1N, note the exact residual difference, then pull the applicable tolerance group's amount and percentage limits from OBA3 or OBA4 for the group actually assigned to the master record or the user. Lay the three numbers side by side: the residual amount, the absolute limit, and the percentage limit applied to the invoice value. The rejection is proven the moment the residual exceeds either limit, and it is proven to be a scope rather than a limit issue if the group assignment field is blank.

If the customer or vendor master record simply has no tolerance group, or the wrong one, assigning the correct group via FD02, XD02 or XK02 is a master data fix and takes effect immediately with no transport. If the user has no tolerance group assigned, correcting the OB57 assignment is a configuration change and needs to move through the normal transport path, even though it looks like a quick fix. If the actual limits in OBA3 or OBA4 are genuinely too tight for the business process (for example, cash discount rounding routinely exceeds the cap), that is a deliberate configuration decision requiring sign-off before the transport is raised, since it changes what every user in that group is allowed to post, not just the one case in front of the clerk. If the block is really a missing account for automatic postings, that configuration gap must be closed before any clearing in that scenario will work, tolerance limits notwithstanding. If the difference is a genuine data error, such as a duplicate partial payment or a wrong invoice amount, the fix is a correcting document, not a tolerance change at all.

The reflex fix is to raise the tolerance group limits, either the specific user's group or the customer or vendor group, wide enough that the difference clears without complaint. This works and the ticket closes, but it applies to every future posting made by that user or against that account, not just the one document in question, and it removes a control that exists specifically to catch wrong invoice amounts, missed cash discounts and duplicate payments before they get buried. Widening tolerances without investigating why the difference exists is how genuine posting errors quietly stop getting flagged, and it tends to surface later as an audit finding rather than as a support ticket.

Tolerance group definitions and limits sit with the FI configuration team, since a change affects every user or account in that group. Master data assignment of the correct group to a customer or vendor sits with whoever maintains that master record, usually a shared AR or AP data team. The handover note should carry the document number, the residual amount, the tolerance group involved, the specific limit breached, and whether the resolution is a master data correction, a config change requiring transport, or a genuine posting error needing reversal.