A natural follow-up to my previous posts on Customer Ledger Entries and the Order to Cash process would be to look at what happens when the numbers don’t match exactly. Because they don’t, very often, and Business Central has a group of features built for that moment.
The problem is that Microsoft used the word “tolerance” for at least six different things. They sit on different setup pages, they post to different accounts, and they fail in different ways. If you learned payment tolerance first — most of us did — you will think the other five work the same way. They don’t, and that is how a junior consultant ends up giving a very confident wrong answer in front of a controller.
This article is for functional consultants who are early in their Business Central career. I go deeper on the accounting side of ledgers in my books, but what follows is the map.
Three questions that explain all of them
Before we go through the six, let me give you the framework I use. Every tolerance in Business Central answers the same three questions:
- What two numbers are being compared?
- How big a difference is allowed?
- Where does the difference go when it is accepted?
That third one is the question juniors skip, and it is the only one Finance really cares about. A tolerance never makes a difference go away. It moves it somewhere — to a G/L account, to a document line, or sometimes nowhere at all, because a couple of these features only allow an action instead of posting anything.
Keep those three questions in your head as we go.
1. Payment tolerance
Compared: What the customer paid against what the invoice expected
Difference allowed: Payment Tolerance % and Max. Payment Tolerance Amount, whichever is smaller
Difference goes to: Payment Tolerance Debit Acc. and Payment Tolerance Credit Acc. on the Customer or Vendor Posting Group
Let’s say we, the owners of Business Central, send an invoice for $1,000 and the customer pays us $998.50. What should happen? Without payment tolerance, we carry $1.50 open forever and somebody writes a journal later to clear it. With payment tolerance, the application closes both entries and posts the $1.50 to an account we picked in advance.
So far so good. Here is the part that catches everybody.
Remember this one
The tolerance amount is recorded onto each ledger entry when that entry is posted. It is not read live from setup.
Which means: you can open General Ledger Setup, type a number into Max. Payment Tolerance Amount, save it, and nothing happens to any of your open invoices. New documents will pick it up. Your old ones will not.
The fix is a batch job. From General Ledger Setup, choose Change Payment Tolerance. And run it once per currency — a blank Currency Code covers local currency only, so every foreign currency you work with needs its own run.
Want to know if it worked? Open Customer Ledger Entries, add the Max. Payment Tolerance field to your view, and look at the invoice that will not close. If it shows zero, your setup never reached that entry. That one field answers most payment tolerance support calls.
One more trap. Clearing Payment Tolerance Warning in General Ledger Setup does not turn payment tolerance off. It only takes away the user’s chance to say no. With the warning off and a limit set, every difference inside that limit is written off silently, and nobody approves anything. If you really want the feature off, set the limit to zero through the batch job.
2. Payment discount tolerance
Compared: The payment date against the payment discount date
Difference allowed: Payment Discount Grace Period, a date formula such as 5D
Difference goes to: The payment discount accounts. The discount is given, just late
This one works on dates, not on amounts, and that is the whole difference between the two.
Payment tolerance asks: is this shortfall small enough to ignore? Payment discount tolerance asks: the discount deadline was Tuesday and they paid on Thursday — do we still give it?
Two things worth knowing early. First, changing the grace period updates Pmt. Disc. Tolerance Date on all open entries right away — unlike the payment tolerance limit, which needs the batch job. Second, when one payment covers several invoices, the date test runs per invoice. A single payment can give a late discount on invoice A and refuse it on invoice B.
And yes, both features can fire on the same application. The late discount is given first, then whatever is left over is checked against the tolerance limit.
3. Application rounding
Compared: The invoice and the payment, after currency conversion
Difference allowed: Appln. Rounding Precision on the Currency card, falling back to General Ledger Setup
Difference goes to: A detailed ledger entry of type Appln. Rounding — not the payment tolerance accounts
This one is directly connected to payment tolerance.
When you apply a foreign currency payment to a foreign currency invoice, the two conversions into local currency rarely match to the cent. That difference of a cent or two is application rounding. Different setting, different account, different entry type.
4. Invoice rounding
Compared: The invoice total against the nearest amount you are willing to be paid
Difference allowed: Inv. Rounding Precision (LCY) and Inv. Rounding Type (LCY) in General Ledger Setup, plus the per-currency fields on the Currency card
Difference goes to: An extra invoice line, posted to the rounding account on the posting group
Notice what makes this one different from everything else on the list. The difference becomes a document line. It prints. The customer sees it. That changes the conversation you have with the client, because now it is not a quiet G/L adjustment behind an application, it is a line on the paperwork.
You need two switches here, not one. The precision fields above, and the Invoice Rounding checkbox on Sales & Receivables Setup and Purchases & Payables Setup. Set the precision and leave the checkbox off, and nothing happens at all. That is a support ticket waiting to be logged.
While you are on the Currency card, do not mix up invoice rounding with Amount Rounding Precision, which rounds line amounts, or Unit-Amount Rounding Precision, which rounds unit prices. Three rounding fields on one page, three completely different jobs.
5. VAT difference
Compared: The VAT Business Central calculated against the VAT a user typed in
Difference allowed: Max. VAT Difference Allowed in General Ledger Setup
Difference goes to: Split across the document lines that share the same VAT identifier
You need this one when a vendor invoice arrives with VAT a cent or two off what Business Central calculates — usually because the vendor’s system rounds per line and yours rounds on the total. Instead of forcing an adjustment journal, we let the user fix the VAT amount by hand, within a limit.
Two switches again. Max. VAT Difference Allowed sets the limit, but nobody can type anything until Allow VAT Difference is turned on — and that lives on Sales & Receivables Setup, on Purchases & Payables Setup, and on the General Journal Template. Three separate places, per area.
Go over the limit and Business Central stops the posting and tells you the maximum. That is the feature working as designed, and it is the answer to “why can’t I post this invoice?”
6. Over-receipt
Compared: Quantity received against quantity ordered
Difference allowed: Over-Receipt Tolerance % on an Over-Receipt Code
Difference goes to: Nowhere financial. The purchase line quantity goes up, and it can be sent for approval
Search for Over-Receipt Codes, set up your codes, then assign a code to an item or to a vendor. When the warehouse receives more than we ordered and the extra is inside the percentage, Business Central lets the receipt through and updates the order instead of rejecting it.
I saved this one for last on purpose, because it is the different one. There is no G/L account anywhere in it. The Required Approval flag on the code sends the over-receipt into the approval workflow instead.
And that is the lesson: a tolerance is not always a write-off. Sometimes it just allows something that would otherwise be blocked.
Worth a mention: planning dampeners
Nobody calls these tolerances, but they do the same job on the planning side. Dampener Period and Dampener Quantity on the item card stop the system from suggesting changes that are too small to be worth doing.
Have you ever opened a planning worksheet and found four hundred lines saying “move this order one day earlier”? That is what happens without dampeners. Everybody learns to ignore the worksheet, and then the worksheet is no use to anyone.
Same three questions, by the way: comparing suggested supply against existing supply, difference allowed by the dampener settings, and the difference goes nowhere at all — the suggestion is simply never raised.
If your junior is on a supply chain project instead of a finance one, this is the tolerance idea they will meet first.
All six, side by side
| Feature | Works on | Set up on | Difference goes to |
|---|---|---|---|
| Payment tolerance | Amount | GL Setup + batch job | G/L write-off account |
| Payment discount tolerance | Date | GL Setup | Payment discount accounts |
| Application rounding | Currency conversion | Currency card | Appln. Rounding entry |
| Invoice rounding | Amount | GL Setup + Currency + 2 checkboxes | An invoice line |
| VAT difference | Manual entry | GL Setup + 3 area setups | Split across document lines |
| Over-receipt | Quantity | Over-Receipt Codes + item/vendor | The purchase line quantity |
Conclusion
Three habits, and I would teach them in this order.
- Answer the three questions before you open a setup page. If you can’t say where the difference will go, you are not ready to set up the feature, and you certainly can’t explain it when Finance asks.
- Expect a second switch. Four of these six need something turned on somewhere else before the limit does anything — the batch job for payment tolerance, the Invoice Rounding checkboxes, Allow VAT Difference in three places, the code assignment for over-receipt. “I set it up and nothing happened” is almost always a missing second switch.
- Check the entry, not the setup. When a tolerance does not work, open the ledger entry and read what is stamped on it — Max. Payment Tolerance, Pmt. Disc. Tolerance Date. The setup page tells you what somebody wanted. The entry tells you what actually applies.
Get those three in place and the rest takes care of itself.
Hope you like it!
Silviu Virlan is a Former Microsoft MVP and independent Dynamics 365 Business Central consultant.
