Chart of accounts
Fewer accounts than you think, with dimensions doing the work that sub-accounts used to. Getting this wrong is the most expensive mistake available in an implementation because everything downstream inherits it.
Services · implementation
We implement the system you bought — NetSuite, Sage Intacct, Acumatica, Dynamics, Odoo, or QuickBooks — on a fixed scope at a published price, with a named lead who is still there at the end. Done means you have closed a month in it, not that the licence is provisioned.
Tell us the system and the shape of the business. We come back with a fixed scope, a price, and a go-live date.
The phases
Eight to twelve weeks for a single entity. Longer engagements get broken into phases with separate scopes rather than quoted as one open-ended programme.
Chart of accounts, entity and dimension structure, approval matrix, and the process decisions that determine what your reporting can do later. This is the phase that matters most and the one most projects rush.
Build to the design. Configuration first — customisation only where a documented requirement genuinely cannot be met otherwise, and each one written down with its upgrade cost.
Load balances and lists with a per-period reconciliation, and connect the surrounding stack: bank, payments, payroll, CRM, commerce.
Your team runs real transactions in a staged tenant. Training is by role and by workflow, not a walkthrough of every screen nobody will remember.
Cutover at period end, then we stay through the first month-end close. The engagement is not finished when the system is on; it is finished when you have closed a month in it.
Four decisions
Everything else is execution. When a deployment fails it is almost never because the software could not do it — it is because one of these was deferred until it was expensive to change.
Fewer accounts than you think, with dimensions doing the work that sub-accounts used to. Getting this wrong is the most expensive mistake available in an implementation because everything downstream inherits it.
What is an entity, what is a department, what is a location, what is a class. Most struggling deployments encoded three of these into one field because nobody decided.
Who approves what, at what threshold, with what delegation when they are away. Vague here means a workflow everyone routes around within a quarter.
What happens on which day, who owns each task, and what the sign-off actually asserts. A close designed during implementation runs; one improvised afterward does not.
Why fixed scope
Every script written during an implementation is an upgrade blocker later, and most of them exist to preserve a process that was itself a workaround for the previous system. Our default answer to a gap is to change the process; the second answer is configuration; the third is a custom module, hosted and versioned by us so it does not become your maintenance problem.
This is unpopular in week three and universally appreciated in year two. We write down every customisation we do build along with the reason and its upgrade cost, so the person who inherits the system knows what it is carrying.
A requirement that was not in the written scope — a new entity, an integration nobody mentioned, a module added mid-project. Change orders are written, priced at the same published rate, and approved before work starts. Our own estimating errors are not change orders, which is the whole point of quoting fixed.
That is a different engagement with a different shape — see implementation rescue. Starting a fresh implementation on top of a failed one without diagnosing why the first attempt stalled usually reproduces it, and the reason is rarely the software.
Questions
Two days of diagnostic produces a written scope, a fixed price, and a go-live date we commit to.