Config audit
For practice leads and ERP owners · Read-mostly access
What is actually in this Acumatica tenant after years of change — an inherited client or your own production company? Which settings are custom, which drifted from standard, and which nobody can explain?
You get. An assessment you can approve without a project budget: the full tenant configuration extracted into a Git repository, plus a written findings report — configured, undocumented, drifted, custom. The repository stays yours.
I extract live Acumatica tenants into versioned YAML and document findings against the gitops model. Read Configuration as code for Acumatica.
how i work
- Work ships in your repository — configuration, scenarios, and reports stay yours after the engagement.
- Runs in your environment, with read-only access wherever the deliverable allows it.
- Upgrade and cutover work runs against rebuilt copies — never against production.
- Everything is documented in plain language for the next consultant, not just for me.
- Verified against the current Acumatica release, twice-yearly majors included.
- Full environment rebuilds need a self-hosted or private-cloud lab; on Acumatica-hosted SaaS tenants the work runs as apply-and-diff against an existing company. Every engagement states which path it covers.
verified today
Measured. Scenario runs complete in about 3–5 minutes per run in CI, measured on a real Acumatica tenant.
Demonstrated. Full rebuild from empty tenant to configured company with running transactions and a clean diff, on the Lab5 sample company. Wall-clock time on your tenant is pinned in the first week of an engagement, not quoted from a brochure.
Built per engagement. Source-system loaders (QuickBooks, Sage 50/100), historical and opening-balance load paths, and merges into half-configured tenants are built when a paid engagement scopes them — not shelf inventory.