Why Your Aged AR Doesn't Match the General Ledger

Two Reports, Two Different Questions

Business Central ships more than one aging report. They don't answer the same question, and most people never notice.

Customer - Summary Aging ages the Remaining Amount on open customer ledger entries by due date. It has a Starting Date field, but that only decides which bucket a due date lands in — it doesn't change which entries show up. The report only ever looks at entries that are still open today. Point it at January 31st, and if something was open then but got paid on February 3rd, it's already gone from the report. Post a few more applications and run it again, and the buckets move again, because the entries moved. The report is fine. It just can't tell you what was true on a past date once that date is behind a payment.

Aged Accounts Receivable is the one that answers "what did we owe on the 31st". You give it a date and it rebuilds each customer's position from the Detailed Cust. Ledg. Entries posted on or before that date.

One is a snapshot of now. The other is a reconstruction of then. If you've been comparing the two, there's your thirteen thousand. It's a different mechanism than the small-balance write-off problem I covered in why your aged receivables report is lying to you — same symptom, an aging report you can't fully trust, different cause.

If you want the developer version of this, including which tables it reads and why, I wrote that up on my blog.

The Number Keeps Moving Because It's Allowed To

Aged Accounts Receivable looks backwards. So it can change after you've printed it.

Somebody posts a payment application dated into a period you closed. Next time you run that period, you get a different answer. Nothing broke. The history actually changed.

Two more leaks, and both are quiet.

A Customer Posting Group where somebody swapped the Receivables Account mid-year. Half your customers post to one account now, half to the other.

Direct Posting left switched on for the receivables G/L Account. Anyone can post a general journal straight into the control account, and that entry never reaches the customer sub-ledger. Not late. Never.

Go check that one now. It takes ten seconds, and I find it switched on more often than I'd like.

Fixing It Once Doesn't Keep It Fixed

Clean all of it up. Find the applications dated into closed periods, sort out the posting groups, switch off direct posting. Your aging ties out.

Then next month somebody posts a payment with the wrong date.

That's the actual problem. The gap between the sub-ledger and the G/L isn't a defect you repair once. It's what happens when nothing is watching between closes. A few entries a month, quietly, until an auditor finds them or a number you already reported turns out to be wrong.

By then it's expensive. Not because the fix is hard. I once chased a 40,000 difference that turned out to be four journals over nine months, about ten minutes each to reverse. Nine months of nobody looking is what turned forty minutes of work into a project.

So Don't Watch It By Hand

Here's where I'm different from most people who'd answer this.

I'm not a functional consultant. I don't come in and retrain your AP clerk. I write AL, I work in the data, and when a problem keeps coming back my instinct is to make the system catch it instead of a person.

So a support block with me isn't a monthly meeting. It's a set of checks running inside your tenant:

• A scheduled job that compares the AR sub-ledger to the receivables accounts at every close and tells you the day it splits, not eleven months later.
• Allow Posting From and Allow Posting To on General Ledger Setup and User Setup, set properly, so the wrong-date postings stop happening instead of getting found afterwards.
• An alert when anything posts directly to a control account, in the week it happens, while the person who did it still remembers why.
• Telemetry going somewhere you'll actually look at it. I do that side with Azure and Application Insights.

Then my hours go on whatever the checks flag, instead of on hunting for it.

That's the part worth paying for. Most consultants sell you their attention every month. I'd rather build the thing once and only charge you for the interesting part.

You're a fit if you're running Business Central without a partner, or with one who only answers when you log a ticket. Or if your close takes three days longer than it should and nobody can say which day is the wasted one.

If you have an internal BC team, you don't need me. If you have one controller doing this on top of payroll and the audit, you do.

And the unglamorous part, out loud: most of what these checks catch is boring. A wrong posting date. A field nobody switched on. That's fine. Boring and caught in March beats interesting and found in December.

Who's Writing This

I'm Silviu Virlan, a Business Central developer and consultant. I run SureHoofERP — SVIRLAN.COM LLC, a one-person Microsoft partner practice — and I've been in this product for about twelve years.

I'm on the technical side. AL development, extensions, integrations, performance, Azure. I've written fifteen books on Business Central, and I write up whatever I'm working on at svirlan.com — telemetry pipelines, analysis views deployed from code, that sort of thing.

One person means you get me. Not a bench, not a handover note. I know your setup because I'm the one who built the checks on it.