Your Aged Receivables Report Is Lying to You

Here's a two-minute test. Open your aged receivables report, sort by remaining amount smallest first, and look at what's sitting at the bottom. If nobody's looked at this in a while, you'll find a long tail of invoices open for pennies — fifty of them, two hundred, sometimes thousands. Every one of those lines is a customer who already paid you, an invoice that never closed, and one more line your credit controller has to skip over every month.

Does Any of This Sound Like Your Month End?

Credit control chases customers who already paid. The balance is $0.80. The customer is annoyed. Your controller is embarrassed.
Month end takes an extra day, because somebody is journaling out small differences by hand before Finance can report a clean receivables number.
Your write-off account is either empty or a mess. Empty means those differences are still hiding inside AR. A mess means they're being posted somewhere with no approval and nobody watching the total.
Statements go out with lines nobody can explain. "What is this $1.20 from March?"
Nobody can tell you the real number. Ask what your real overdue receivable is, and the answer starts with "well, if you ignore the small ones…"

Any one of these on its own is just annoying. Put them together and you can no longer trust your receivables ledger without adding an excuse to every number — and a ledger you have to explain away is a ledger you've stopped using to make decisions. This is the same territory we cover in getting real visibility into where your customer payments stand, and it comes up alongside prepayment credit handling more often than you'd expect — both are places where Business Central's AR data model doesn't match how finance teams naturally think about a balance.

So Why Does It Happen?

Business Central has a feature built for exactly this situation, called payment tolerance. It closes an invoice when the payment comes in slightly short or slightly over, and posts the difference to an account you choose in advance. Good feature. Almost never set up correctly. There are three reasons, and I see all three often.

It was never turned on. The system went live, nobody on the project asked what should happen when a customer pays $998.50 against a $1,000 invoice, so the answer became "leave it open forever."

It was turned on in the wrong place. Somebody typed a limit into General Ledger Setup and assumed that was that. It isn't. Business Central stamps the tolerance onto each ledger entry at the moment that entry is posted, so a change in setup only affects invoices you post from now on — all your older ones stay exactly as they were. There's a batch job that fixes this, and it has to be run once for every currency you use. This is the most common reason a fix doesn't stick.

It was turned on too far. The warning that lets a user say no to a write-off was switched off, usually because it kept stopping the team during cash allocation. Now every small difference is written off silently, with no approval and nobody watching the total. That's a real audit finding — I've watched a client discover it during the audit itself, which is a bad time to find out.

And that's just one feature. Business Central has at least half a dozen things it calls a tolerance — over-receipt on incoming goods, VAT differences on vendor invoices, three separate rounding settings — and each has its own version of the same story.

What Is It Actually Costing You?

Not in software terms — in your terms. A credit controller spending three hours a month cleaning up noise that shouldn't be there. A month end that can't finish until somebody clears the small stuff. An auditor asking who approved the write-offs and not getting a good answer.

None of that shows up as a line-item cost anywhere. All of it is real, and it keeps costing you for as long as the setup stays wrong.

What Does Fixing It Look Like?

Shorter than you'd expect. This is setup work, not development — no code, no upgrade, no downtime.

Read the current state. What's actually stamped on your open entries, currency by currency, against what your setup pages say. These two often don't match, and that's usually the whole problem.
Agree the policy with Finance, not with IT. What difference is small enough to write off? Who's allowed to accept it? Which account does it go to? Does anybody need to approve it? It's a fifteen-minute conversation and almost nobody has it.
Apply it to the old invoices too. Your existing open entries need the batch job, once per currency. This is the step everybody misses.
Clear the tail. Once the setup is right, those old small balances can be closed in one controlled pass you can audit, instead of one journal at a time.
Write it down. One page, so the next person who opens General Ledger Setup knows what these fields do and doesn't undo your work.

Most fixes take a few days from start to finish. What you get back is a receivables ledger you can read without doing math in your head first.

Why This Is the Kind of Problem I Look For

I've been working with Dynamics NAV and Business Central for 12+ years, as a former Microsoft MVP, and the area I know best is the part many consultants would rather avoid: costing, inventory valuation, and how the ledgers work underneath what your users see on screen. Payment tolerance sits right in the middle of that.

I also work directly with you — no account managers, no team of juniors learning your system at your expense. You get a former Microsoft MVP who reads the ledger, tells you what's actually wrong, and fixes it properly.

If anything above sounded familiar, the first conversation is free — usually enough to tell you whether you have a real problem or just a clean-up job. Bring your aged receivables report. Book a free discovery call at /contact and let's look at it together.

Book a Free Discovery Call