Business Central Insights
You run your monthly or year-end close the same way you always have. Nobody touched the setup. And yet the output looks different — more lines than usual, dimensions or business unit codes missing, totals that don't tie out the way they used to. Nothing in your process changed. But something did: Business Central did.
Business Central SaaS updates itself automatically — monthly minor updates plus two major release waves a year. Most of the time that's a good thing: security patches, bug fixes, and new features land without anyone lifting a finger. But "automatic" also means updates can change how existing processes behave, and nobody on your team gets a heads-up beyond a release note most people never read.
The close process is a common place this shows up, because it touches configuration options, dimensions, and posting logic that don't get exercised every day the way a sales order does. A setting that quietly stopped being respected, or started behaving differently, can go unnoticed for weeks — until someone tries to close the books and the output doesn't match what everyone expects to see.
One version of this we've seen reported: the Close Income Statement process, which is supposed to post one consolidated closing line per G/L account, starts posting one line per underlying source entry instead — and dimension values or business unit codes that used to populate come out blank. The option controlling that behavior hadn't been touched. The output changed anyway.
That's the pattern to watch for generally, not just this specific case: a process option that's supposed to control aggregation or grouping stops being applied consistently after an update, and the report or posting result comes out granular and stripped of context instead of clean and summarized.
Before assuming Microsoft broke something, rule out your own configuration. Run the process in a sandbox with the option set one way, then the other, and compare the actual output — not just what the setting is supposed to do, but what it actually produces on your current version. If both settings produce the same result, that's a clean, reproducible case worth escalating rather than a configuration question.
If you have a sandbox on a newer minor update than production, restore a fresh copy and re-run the same test. Minor version fixes ship quickly, and there's a real chance the behavior you're seeing has already been corrected upstream.
Don't post whatever the process generated if it doesn't look right. Closing entries carry a closing date and closing-specific posting logic, and unwinding a wrong closing posting is significantly more work than getting it right the first time. If you're against a deadline and the output is unusable, it's usually faster to pull the generated lines into a spreadsheet, re-aggregate them the way you actually need, and post a clean manual journal with the same closing date and balancing account than to fight the automated process under time pressure.
The real fix isn't a one-time workaround — it's catching this kind of thing in a sandbox before it reaches your production close. That means someone actively watching each monthly and major-wave update, testing the processes that actually matter to your business (not just the ones Microsoft flags), before the update reaches production. That's exactly what ongoing SaaS upgrade management is for — sandbox testing ahead of every update so a close-process surprise gets caught in a test environment instead of during your actual close.
If a Business Central update has ever changed something you depend on without warning — or you want someone actively watching updates before they hit your production environment — let's talk. Book a free discovery call at /contact and we'll walk through what proactive update testing would actually look like for your setup.
Book a Free Discovery Call