The monthly report never guesses a line. Not even the month more than half of it was missing one.

A report that was expensive because it lived outside the ERP

We sell our transformation programs in days, broken down by functional domain inside multi-year increments. Every month, a numbered report goes out to the client, with the budget in days per domain, days consumed, the percentage, what’s left, cumulative since January first.

Before, that document was built by hand, outside the ERP, from timesheet exports. Three to four days a month, just to rebuild a table nobody really read closely until something in it was wrong. The document slipped. It arrived late more often than on time.

The real cost wasn’t only the days spent on it. It was the mental weight of knowing that document was hanging over the whole month until it got done.

Same truth, not a separate report

The shift happened in two steps. First a prototype, still outside the ERP, allocating budget pro rata because there was no way yet to tie a ticket to a domain. Then the model moved into Business Central: domains are budgeted on the project, tickets attach to them, and the report regenerates from the same time entries that feed the project ledger, which is to say the invoice. One truth, two uses.

That has a cost, and it isn’t paid on the report, it’s paid on data entry. A billable line can no longer be submitted without an external ticket number, a work type, or with a description that merely copies the task’s own label, because that description ships to the client exactly as written. We made entry slower to make the report truer. It’s the same trade we cover in our guide to Business Central customizations to avoid: the shortcut that saves a minute today costs an hour of doubt later.

A rule set before we needed it

One consequence of that setup: a task that was never broken into domains has nothing to hand the report. Time booked against it stays without a domain, literally.

The temptation is to move that time onto a task that already has domains, so the report comes out round. The closing procedure forbids it, and it forbade it before the case ever showed up: reassigning those days to a broken-down task would claim domains nobody had actually claimed. The rule holds in one line, show the gap, never fill it with a plausible label.

It isn’t a rule about one particular task. It’s a rule about what the report is allowed to claim, full stop.

The month the rule earned its keep

One month, a check flagged before the report went out that 56 percent of it sat under the raw label of a task that had never been broken into domains. The alert was informational, not blocking. It didn’t stop the report from being produced, it just made the fact impossible to miss.

What followed wasn’t a scramble. It was a procedure doing exactly what it had been written for. The shortcut that would have made the number disappear stayed off the table. The report shows that line for what it is, real time with no claimed domain, instead of what a broken-down task might have made it look like. The hole stayed visible, and the fix went where it belonged: onto the task that had never been broken down.

What that verifies, once a month

An automated client report is not proof of reliability on its own; a script fabricates a number as fast as a person fabricates an approximation. What makes this one checkable is that it has nowhere to invent from: it can only say what the time entries say, and when they say nothing on a point, it shows that.

It also changes what a client can do with the number they receive. A report that can say it doesn’t know about one line can also be trusted on every other one, the ones where it states a consumed budget with no hedge attached. That’s what a hand-rebuilt spreadsheet is missing, not the skill of whoever built it, but the document’s own ability to refuse to claim what it doesn’t know.

It’s the same discipline we hold on an AL extension that has to survive its own upgrades: code that cheats with its own data eventually has to choose between lying to the client or breaking silently. We closed off that option before it ever came up.

If your client reporting still lives outside your ERP

The question worth asking isn’t whether the report ships on time. Plenty do, including ones rebuilt by hand from a spreadsheet.

The question is what happens the month a piece of data is missing. Does it show, or does it get quietly spread around so the total still looks tidy. The difference never shows on the report that’s going well. It shows on the one that, one month, shouldn’t.

That’s part of what a Business Central clarity review goes looking for.