Written for fractional controllers and outsourced accounting firms who own the close for a whole book of clients. One standard close and reporting setup instead of ten workaround stacks.
Each client's NetSuite customisation is unique because the base product required workarounds for standard accounting needs. A fractional controller managing ten clients manages ten different workaround stacks.
The dependency model changes — the controller owns the configuration, not the implementation partner.
Whether an agent can post to the ledger is decided by whether the schema is open to it, not by the size of the customer. That makes it a design decision available at 50–500 employees, not an enterprise-tier feature.
The questions this role raises, in the order they raise them.
Every capability a client depends on is checked before the SOW, not discovered mid-cutover. Anything the base product does not cover is named up front with a decision attached — rebuild it, drop it, or stay. Scope exclusions are by capability, never by NetSuite tier.
The client's old system stays live until the cutover weekend — a parallel run, not a big bang. The price is fixed, so an overrun is ours to absorb rather than theirs or yours. Rollback is documented and tested per step before cutover, and if the bar is missed they stay on NetSuite.
Odoo Community is LGPL and runs without us. A client can take a full PostgreSQL export at any point and self-host or move to another Odoo provider, so recommending it does not make your firm their single point of failure.
The workflows this role owns, each rebuilt on an ERP you own.