There is no build phase the customer waits through blindly. Every working session follows the same loop, in the customer’s own tenant, on real screens with the customer’s sample data: show the Fit Ledger line, configure it live and no-code, the customer drives the change, verify with sample data, log it and tick the line.
If the customer is not in the session, the session does not happen. The key user should be driving by T-14; if TRANXACT is still at the keyboard on T-13, raise it in the standup as an adoption risk.
Seven days, structure before transactions (proposed default)
| T-day | Focus | Configured |
|---|---|---|
| T-17 | Structure | Entities, chart of accounts, fiscal calendar, dimensions |
| T-16 | Money & compliance | Currencies and FX, tax codes, document numbering, banks |
| T-15 | People & access | Roles and permissions, SSO groups, approval hierarchy |
| T-14 | Master data | Customers, vendors, items, employees — ASK bulk-creates from extracts |
| T-13 | Flows & rules | Approval flows, posting, matching and pricing rules |
| T-12 | Module specifics | CRM pipeline, supply-chain costing, HR pay elements, module toggles |
| T-11 | Integrations & queues | API clients, bank / tax / payroll endpoints, queues per role |
Keep the order even when the Fit Ledger’s differs: structure first means migration mapping can start on T-15, and the GL mapping everything else hangs from exists before master data does.
ASK does the grunt work
Bulk-create 2,400 customers from an extract with payment terms by segment; draft a posting rule for freight split by the receiving warehouse’s cost centre; generate an AP clerk who can enter but not approve invoices over 10,000; list every approval flow without a fallback approver. ASK does it under the same permissions and audit log as a human click, and the key user reviews every result before the line is ticked.
Requests that sound like code
| "We need…" | The configuration that answers it |
|---|---|
| Our unique approval process | A multi-step approval flow with amount, entity and dimension rules |
| A custom invoice layout | A document template with fields, logo and language per entity |
| A field that does not exist | A no-code custom field, usable in reports and rules |
| Our legacy report exactly as is | The report builder or a dashboard — challenge the layout; often "not needed" |
| An interface to the bank or MES | An API client with a scoped role; file exchange where needed |
| Alerts when X happens | A role-aware action queue rule |
Integrations on the clock (proposed default)
List and owners by T-18; API clients and partner test endpoints by T-13; integration tests by T-10 (payroll T-9, BI T-6; SSO by T-17, because the rehearsal needs it); end-to-end in the dry run at T-3; production switch at T-0.
A partner that cannot provide a test endpoint by T-13 moves that integration to T-Plus with a manual interim step — a manual bank file upload, a portal upload by finance, payroll run in legacy with a journal import. SSO has no interim: it is required for the rehearsal.
Calderwood’s bank provides its test endpoint on time; its tax portal’s sandbox is still not issued at T-13. The tax integration becomes a T-Plus line, and finance uploads e-invoices to the portal by hand for the first weeks — rehearsed at T-1 like everything else.
Try it On T-12 a key user asks for the vendor-invoice screen to show a field the legacy system had. Is that code?
No — it is a no-code custom field on the form, usable in reports and rules. It gets a Fit Ledger line, is configured in the session with the key user driving, verified with sample data, logged in the Configuration Workbook and given a configuration check in the Test Plan.