Clearing Customers in SAP | Customer clearing

Tolerances and Timing: The Messy Edges of SAP Customer Clearing

What Did Finance Teams Learn About Reconciliation in 2025?

A customer pays £97,346.42 against an invoice of £97,346.50. The 8p difference falls inside almost any sensible SAP customer clearing tolerance, so the system writes it off and posts the clearing without anyone touching it. Sometimes. Other times, a reason code is missing on the user’s profile, a tolerance group is mis-assigned, or the difference creeps past the configured limit by a few pence on a high-volume customer. The 8p sits as a residual that nobody bothers to write off, and the account looks open against a customer who has already paid in full. Multiply that by a thousand customers paying weekly, and the working-capital cost is no longer rounding error. The Hackett Group’s 2025 European Working Capital Survey put excess working capital across European companies at €1.4 trillion, equivalent to 14% of aggregate revenue. Tolerance leakage is one of the small line items inside that figure.

How SAP customer clearing tolerance handles small payment differences

How SAP payment difference tolerance is configured

SAP’s customer payment-difference behaviour is governed at tolerance-group level, with no out-of-the-box per-customer or per-invoice configuration. Two group types interact. OBA3 defines customer and vendor tolerance groups, assigned to the customer master record, and sets the maximum permitted difference in absolute amount and percentage. OBA4 defines user tolerance groups, assigned via OB57, and caps the write-off any individual user is allowed to post. Where both apply, the more restrictive of the two wins.

Inside tolerance, the system can post automatically and route the difference to a configured G/L account, typically a payment-difference or cash-discount account depending on the path. Outside tolerance, the user gets three options: leave the items partly cleared, raise a residual item for the unsettled balance (which carries forward as a new open document), or post the entry as a partial payment so the original invoice stays open with the cash recorded against it.

Reason codes change the arithmetic. Where a reason code is assigned during clearing, the system can route the difference to a G/L account associated with that code and bypass the standard tolerance check entirely (SAP Help Portal, Reason Codes). The mechanism works as designed; the friction shows up in operations. Reason codes have to be configured and mapped, then remembered by the user posting the clearing. In a high-volume AR team, that is where the tidy theory meets the messy week.

The granularity limit on SAP customer clearing tolerance is the part that surfaces in steering committee decks. SAP payment difference tolerance is set at group level. To run a 5p tolerance under £100, a £5 tolerance between £100 and £10,000, and a £50 tolerance above £10,000, a finance team has to create and maintain enough tolerance groups to cover the segmentation, then keep the customer master assignments in sync. There is no out-of-the-box value-band model. Teams that want it tend to live with a single tolerance setting that is too loose for some customers and too tight for others, or they end up maintaining custom logic.

What is the difference between a residual item and a partial payment in SAP?

A residual item closes the original invoice and creates a new open item for the unsettled balance, carrying forward only the difference. A partial payment leaves the original invoice open and records the receipt as a partial against it, so both the receipt and the invoice remain visible until the next instalment clears the balance. Residuals reset the document chain; partial payments preserve it (SAP Help Portal, Partial Payments Versus Residual Items).

SAP remittance advice processing when the cash arrives later than the advice

SAP supports payment advices as a distinct object that can be created or imported ahead of the corresponding bank statement line. Once an advice exists, the system matches the open items it references and holds them in an advised state. When the bank credit subsequently posts, the advice is picked up by automatic clearing and the items move from advised to confirmed without further manual work (SAP Community, Bank Payment Advice / Remittance Advice; SAP Knowledge Base 2533891, Zero Amount Clearing Via Remittance Advice).

The mechanism assumes structured advice data flowing in. Typical shapes are EDI, IDoc, MT940 with payment-advice content, or manual entry through FB13 or FBE1. The common real-world case is different. A customer emails a PDF or a spreadsheet two days before the bank credit lands. That information sits outside the formats the standard advice object accepts. It sits in someone’s inbox until the bank line arrives and the AR team re-keys, or until the team manually creates a payment advice from the PDF. FEBAN can post-process bank lines that arrive without matching advice context, but the work is reactive: the team only opens the items after the bank credit has already posted.

This is where SAP remittance advice processing under the standard model gets stuck. The data exists, the customer has sent it, and the open items are sitting there waiting to be matched. The bottleneck is the remittance format, which the team hits days before the bank line is even relevant.

Where AR teams hit the friction in practice

Five scenarios show up repeatedly in conversations with finance leadership in mid-to-large UK retail and consumer goods.

Partial-deduction retail self-billed remittance. A large retailer settles 380 invoices in one payment and deducts a marketing levy and several logistics and quality penalties across forty of them. The bank credit shows the net figure. The remittance file lists the lines. SAP standard cannot decompose the deductions against the original invoice line items without a rule per deduction type, so the AR clerk works through the file by hand and posts residuals on the deducted lines.

Freight short-pay. The customer pays £100,000 against a £100,250 invoice, deducting £250 for damaged stock. The deduction sits well outside the OBA3 tolerance group threshold, the reason code for damages exists in OB42 but is not in the user’s habit, and the residual posts without it. The £250 hangs as an aged item until someone reconciles back to the credit note that should have been raised.

Group remittance covering multiple entities. A buying group sends one payment covering invoices across three of the supplier’s company codes. Standard SAP cannot split the bank line and post across entities in a single auto-clearing step. The work routes to manual journals or a separate cross-company-code clearing job, and the group has to be unwound before the customer accounts can flatten.

PDF email remittance arriving days ahead of bank credit. The customer’s AP team emails a PDF on Monday. The bank credit lands on Wednesday. By Wednesday afternoon, the PDF has already been forwarded twice and is buried in the team mailbox. The AR clerk re-keys from a printout and posts the clearing manually because the advice was never staged in SAP.

Missed reason code on a write-off. A 30p difference is written off against a generic payment-difference G/L account because the user did not assign the deduction reason code. Individually, it is invisible. Across a quarter, the analytics on disputed deductions degrade because the data was never captured in a coded form.

In every one of these scenarios, the line ends up in F-32 for someone to clear by hand, often the same someone who is supposed to be closing the month.

Closing the residual gap inside SAP

The residual gap closes earlier in the process, where the matching layer reduces how often a residual decision is needed in the first place. Configurable OBA3 tolerance group settings under SAP payment difference tolerance still apply, but they fire less often because fewer borderline differences make it through to the clearing step.

The BEST Customer Clearing module takes that approach inside SAP. The module ingests customer payment advice, including PDF and emailed remittances, and validates the lines against open items in the customer master. Matching runs across multiple customers and multiple company codes from a single remittance, with user-friendly tools for managing residuals and short payments where they remain. The matching runs on the remittance, the clearing posts when the bank line lands, and users keep their existing SAP authorisations and audit trail throughout.

Ardagh Glass runs the module on 9,000+ remittance lines per month at a 99.9% clearing rate. A R200 million remittance covering 1,000 line items is uploaded and matched in 11 seconds, against approximately four hours of manual keying. The volume arithmetic is what matters: at that throughput, residuals stop being a daily papercut and become a small structural exception list the team works through deliberately rather than reactively. One overdue account dropped from R77 million to R6 million after rollout, and month-end shortened by half a day.

Amka tells the same story at a different volume shape. Over two years, 97% of 143,000+ lines have been auto-cleared. The remittance from Shoprite, a consolidated retail self-billed file that used to take hours or days to process, now takes 30 minutes. The headline is the time-saving. The deeper signal is that fewer of those lines reach the residual workflow at all, because the matching layer caught them upstream. Vodafone has reported that internal SOX audit requirements continue to be met, with auditors having direct access to BEST inside the SAP environment, which matters when the same finance director is signing off both the working-capital number and the controls testing.

More on the wider reconciliation toolset sits in BEST’s account reconciliation software guide and the customer clearing case studies library. The module is SAP-certified under three current certifications, including S/4HANA Cloud Private Edition and BTP.

The takeaway for an SAP AR function carrying tolerance and timing pressure: the levers worth pulling sit inside SAP. SAP customer clearing tolerance, set on OBA3 and OBA4 groups and kept in sync with reason codes, takes care of routine differences. Most of the working-capital pressure on a high-volume AR team comes from residuals that never reach a tolerance check at all: the upstream matching decides whether a residual is created in the first place. Book a demo to see Customer Clearing handle a live remittance.

Sources used

Book A Demo