From first conversation to a working register in about four weeks.
Implementation starts with the operating process: which transactions and documents arrive, who reviews them, where evidence belongs and what output the team needs. The register, personal interfaces and recognition workflow are then configured around that agreed scope.
Written by the Fundamental View editorial team. Updated 28 October 2026. About four weeks is the stated typical timeline, not an unconditional deadline. Exact deliverables, responsibilities, dependencies and commercial terms require written agreement.
Week 1: discovery and boundaries
Review the current reporting process: entities, transaction types, document channels, reviewers and points of delay. Fictional or redacted examples are sufficient at this stage. Record constraints on accounts, storage and access, and distinguish current requirements from later integrations.
The discovery output should include supported cases, exclusions and unresolved decisions. If direct bank feeds, formal statutory accounts or performance analytics are expected, confirm whether they are genuinely in scope rather than inferring them from the word “accounting”.
Week 1: register structure
Define fields, categories, entities, currencies and required supporting documents. Agree the meaning of dates, review states, original and reporting amounts, internal transfers and exceptions. This field dictionary becomes the basis for configuration and acceptance testing.
Weeks 2–3: interfaces and automation
Each user receives the configured personal interface for submitting transactions and documents. Names, account numbers and other identifiers are masked before AI reads a document. Storage and the register are set up in the client's own Workspace. A customisable application is described as in development and should not be treated as an already delivered capability.
Week 3: test ordinary cases and failures
| Case | Expected result | Owner before launch |
|---|---|---|
| Standard supported document | Fields are proposed, confirmed and linked to the source | Operations reviewer |
| Unreadable page | No guessed values; an exception remains visible | Document submitter and reviewer |
| Missing required field | The record cannot be treated as confirmed | Operations reviewer |
| Repeated submission | The duplicate is investigated before another entry is accepted | Register owner |
| FX rate unavailable | The original value remains; the rate exception has an owner | Designated FX reviewer |
| Correction | The agreed correction path and history are followed | Register owner |
| Access removal | The departed user's access no longer opens the record or evidence | Client account or IT owner |
Week 4: launch and handover
Connect users, monitor the first operating cycle and document account ownership, operating instructions, known limitations and support routes. Handover should include a working retrieval test, not only a configuration list. The team needs to find a record, open its evidence, resolve an exception and request a correction.
Dependencies that can change the timeline
- Late agreement on field definitions, entity scope or acceptance examples.
- Unavailable account owners or delayed access approvals.
- Historical-data cleaning and migration, which are scoped separately.
- Additional document classes, networks, integrations or exception rules.
- Legal, procurement or security review of actual providers and responsibilities.
Record changes to scope explicitly. A fixed calendar should not pressure the team into accepting unreviewed data handling or incomplete test cases.
Who does what
- Client operations team: defines records, reviewers and acceptance examples; performs operational confirmation.
- Fundamental View implementation lead: configures the agreed workflow and documents its operation and limits.
- Client account or IT owner: confirms access, storage, offboarding and organisational requirements.
- Client professional advisers: remain responsible for accounting, tax, legal and investment judgements.
Annual support and later scale
Support after launch is agreed in writing: its scope, hours and response times belong in the agreement. Historical migration, SQL reporting and additional integrations are scoped separately. Do not interpret SQL migration as automatic compliance, security or unlimited capacity.
Prepare for a first conversation
Bring a short process description and the problem to solve. Do not send balances, identity documents, wallet keys or confidential files through the website form. Useful preparation includes one synthetic ordinary case and one example of every recurring exception.
Related guides
- Define the transaction register
- Specify the document-to-record path
- Confirm data and access responsibilities
- Scope a later register migration
Discuss your workflow
Describe the record-keeping problem you want to solve. Please do not include confidential financial information or documents in the enquiry.
Discuss implementation