A couple weeks into a Business Central rollout, the owner of a water treatment company leveled with us on a call: about a month back they'd discovered their previous bookkeeper hadn't been keeping the books properly, and cleaning it all up was going to take weeks, maybe months. Meanwhile, they still wanted to go live in August. That tension (messy data versus a real deadline) is one of the most common spots we see growing companies get stuck.
The instinct to perfect everything first is the trap
When your data is a mess, the natural reaction is to hold off until it's spotless. On a deadline, that's a good way to miss the date entirely. The better move is to separate the data you need clean to go live from the data you can keep improving after.
Their plan reflected this. Build the platform, load the data they have, and edit as they go rather than freezing the project until every record is perfect.
What has to be right at go-live
Not all data carries the same weight on day one. A rough way to triage it:
| Data | How clean it needs to be at go-live |
|---|---|
| Customer and vendor master lists | High. These drive everything downstream, so duplicates and mismatched counts need resolving first. |
| Item costs | High-ish. Costs give you a working baseline even when sell prices vary by customer. |
| Customer sell prices | Lower. If you price per customer, those can live in separate price lists you build over time. |
| Historical detail | Lowest. Correct as you go once the system is running. |
In their case, two versions of the vendor list had different vendor counts, so the first job was simply confirming which list was correct. That kind of cleanup can't be skipped, because a bad master list creates errors on every transaction that touches it.
Even if you can't nail down a single sell price because you charge different customers differently, loading item costs gives project operations a reliable baseline to work from.
Get the setup that drives your GL right the first time
One piece worth slowing down for is what Business Central calls posting groups. In plain terms, these are the rules that tell the system which general ledger accounts a transaction should hit based on the customer, vendor, or item involved. With something like fifteen different revenue accounts in play, you want that logic mapped correctly, because it's what lets finance trust that transactions land in the right place automatically.
The good news is posting groups aren't set in stone. When costs shift (say a raw material gets hit with a tariff), you can adjust a posting group or create a new one and reassign it. The point of defining them well up front is so your team can make those changes later without calling in help every time.
A practical way to divide the work
- Nail down the master lists (customers, vendors, items) first, since everything else depends on them.
- Load item costs as a baseline, even if sell prices come later.
- Define posting groups with your accounting lead so the GL logic is correct on day one.
- Go live, then keep correcting historical and detail data on a schedule that doesn't hold up the launch.
The takeaway
A go-live date and imperfect data can coexist. The trick is being honest about which records must be right before you flip the switch and which ones you can clean up while the system runs. Draw that line early and the deadline stops feeling impossible.
If you're staring down a go-live with books that aren't where you'd like them, we're glad to help you figure out what has to be fixed now and what can wait.