T-Minus: configure in the open
The daily configuration loop, the seven configuration days from T-17 to T-11, ASK as an accelerator, configure-never-code patterns, the per-module checklist, and integrations inside the countdown.
The daily configuration loop
- Show the Fit Ledger line.
- Configure it live, no-code.
- The customer drives the change.
- Verify with sample data.
- Log it and tick the line.
| Who | Where | Output |
|---|---|---|
| The Ledger Architect leads and the key user co-drives | In the customer’s own tenant | A tenant visibly closer to go-live every day |
| The Countdown Owner joins for scope calls | On real screens with the customer’s sample data | A Configuration Workbook row per setting |
| The Adoption Navigator watches for role and queue needs | Never on a whiteboard or in a document | A configuration check added to the Test Plan |
There is no build phase the customer waits through blindly: 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 of configuration (proposed default)
| T-day | Focus | Configured | What depends on it |
|---|---|---|---|
| T-17 | Structure | Legal entities, chart of accounts, fiscal calendar, dimensions | Migration mapping (GL) |
| T-16 | Money & compliance | Currencies and FX, tax codes, document numbering, banks | Opening balances, open items |
| T-15 | People & access | Roles and permissions, SSO groups, approval hierarchy | Rehearsal roles, queues |
| T-14 | Master data | Customers, vendors, items, employees — ASK bulk-creates from extracts | Mock load M1 |
| T-13 | Flows & rules | Approval flows, posting rules, matching rules, pricing | Integration tests |
| T-12 | Module specifics | CRM pipeline, supply-chain costing, HR pay elements, module toggles | Rehearsal script |
| T-11 | Integrations & queues | API clients, bank / tax / payroll endpoints, action queues per role | Gate: configuration complete |
Keep the sequence even if the Fit Ledger order differs: structure before transactions, so migration mapping can start on T-15.
ASK as a configuration accelerator
ASK does the grunt work at machine speed, under the same permissions and audit log as a human click:
| Job | Example request |
|---|---|
| Bulk-create master data | "Create these 2,400 customers from the extract, with payment terms by segment" |
| Draft posting rules | "Post freight on purchase invoices to 5120, split by cost centre of the receiving warehouse" |
| Generate role set-ups | "An AP clerk who can enter but not approve invoices over 10,000" |
| Check configuration | "List every approval flow without a fallback approver" |
Every ASK-generated configuration is reviewed by the key user before it is ticked in the Fit Ledger. The audit log shows who asked, what ASK did and who approved it.
Configure, never code: common patterns
| Request that sounds like code | Configuration pattern | Where |
|---|---|---|
| "Our approval process is unique" | Multi-step approval flow with amount, entity and dimension rules | Workflows |
| "We need a custom invoice layout" | Document template with fields, logo and language per entity | Output templates |
| "Special pricing per customer group" | Price lists, discounts and validity by segment | CRM / pricing |
| "A screen field that doesn’t exist" | A custom field on the form, used in reports and rules | Forms (no-code) |
| "Our legacy report, exactly as is" | Report builder or dashboard — challenge the layout, often "not needed" | Reporting |
| "An interface to our bank / MES" | An API client with a scoped role; file exchange where needed | Integrations |
| "Alerts when X happens" | A role-aware action queue rule | Action queue |
When no pattern fits, the options are T-Plus or an honest no. In-cluster code goes through the extension framework and never through the countdown.
Module checklist (wave 1 modules only, proposed default)
| Module | Typically configured in the countdown |
|---|---|
| Accounting | Entities, chart of accounts, calendar, tax, banks, posting rules, closing checklist |
| CRM | Pipeline stages, price lists, quote / order flow, credit limits |
| Supply Chain | Warehouses, costing method, reorder rules, receiving and matching |
| HRMS | Org structure, pay elements, leave rules, payroll calendar |
| Manufacturing | Work centres, BOMs, routings, traceability rules |
| EHR | Clinical roles, patient billing, payer rules, consent |
| Student Lifecycle | Programmes, admissions flow, fees, alumni |
| Platform | Roles, approval flows, queues, ASK tier, languages |
Only wave 1 modules appear in the countdown; everything else is a T-Plus toggle on the same ledger.
Integrations inside the countdown (proposed default)
T-18 list and owners → T-13 API clients and test endpoints → T-10 integration tests → T-3 end-to-end in the dry run → T-0 production switch.
| Integration | Typical pattern | Test by | Interim if not ready |
|---|---|---|---|
| Banking & payments | API / host-to-host SFTP | T-10 | Manual bank file upload |
| Tax / e-invoicing | API | T-10 | Portal upload by finance |
| Payroll provider | API / SFTP | T-9 | Payroll run in legacy, journal import |
| Identity (SSO) | SAML / OIDC | T-17 | None — required for the rehearsal |
| BI / data warehouse | Scheduled extract | T-6 | T-Plus |
Partners — banks, payroll, tax — need test endpoints by T-13. A partner that cannot provide one moves that integration to T-Plus with a manual interim step.
Values marked proposed default are the methodology’s recommended starting points. Confirm each one per engagement; the contract, order form and SLA prevail.