Every finance team has a process no product covers — a regulator's bespoke return, a partner settlement nobody else runs, a reconciliation between two systems only you have. We build those, to your requirement, on the same foundation our product lines run on: pure deterministic engines for every figure, AI for documents and questions, hash-chained audit, maker-checker and tenant isolation from day one. You get a product, not a project — and it keeps working after we leave.
Bespoke finance automation usually ends one of two ways: an IT project that took a year and nobody can change, or a consultant's workbook that works until the person who built it leaves. Adding AI has mostly added a third: a demo that cannot be audited.
Months of requirements, a rigid result, and every rule change is a change request.
Fast and fragile. Nobody can prove what it computed last year.
Impressive on stage. It cannot say where a number came from, so it never reaches the close.
Your build inherits a platform that already does the hard, boring parts that make finance software trustworthy.
Every calculation is a tested pure function from data to data — the same discipline behind our 336, 406 and 725-test engines.
Models read documents, draft text and answer questions over stored facts. They never compute or post a figure, and their numbers are validated.
Hash-chained audit, maker-checker, role-based access and row-level tenant isolation are already there.
Rules, thresholds and mappings are versioned data your team edits after go-live — no change request.
A custom build posts into the same ledger, close and reporting as our product lines.
Standard Postgres, open export formats. Your data and your rules leave with you.
Examples of the bounded, high-value workflows that fit the model.
Fixed scope, shipped in increments, owned by you at the end.
One to two weeks with your controllers. We write the rules down as they are, including the exceptions nobody documents.
Before code, we agree worked examples with known answers. They become the acceptance tests.
Pure engines first, then data, then screens on the platform design system. AI added only where it saves real work.
A period run beside your current process; differences explained, not waved through.
Rules as configuration, a runbook and the test suite. You change it without us.
We use AI where it removes real effort — and design the boundary so an auditor can live with it.
The pattern behind our lease, lessor and spend intake: confidence, provenance and a second review before anything is committed.
The Expense Intelligence pattern: numbers validated against an evidence pack, or the text is discarded.
The Lending and Expense Intelligence pattern: a reviewed query catalogue or metric registry, never generated SQL.
The migration-mapping pattern: the agent proposes, a person approves, the engine applies.
Across every FinIFRS product the rule is the same: a deterministic, tested engine computes and stores every figure first. AI reads documents, drafts sentences and answers questions over what is already stored — it never computes, posts or approves an amount.
Every build follows the same rule our products do: anything a controller might argue about is data.
Against the two usual routes to bespoke finance automation.
| Capability | IT / SI project | Consultant workbook | FinIFRS |
|---|---|---|---|
| Time to first release | 6–12 months | Weeks | ✓ 4–8 weeks |
| Audit trail and maker-checker | If specified | — | ✓ Built in |
| Golden tests with known answers | Rarely | — | ✓ Always |
| Finance edits rules after go-live | Change request | Edit the macro | ✓ Configuration |
| AI that cannot invent a figure | — | — | ✓ By design |
| Posts into your close and reporting | Integration project | Copy-paste | ✓ Same platform |
You own your data, rules and configuration, all exportable in open formats. The build runs on the FinIFRS platform under your licence.
No. A custom build can stand alone, though most clients find it posts into a product line they already use.
Yes. The AI layer is provider-agnostic per tenant, and any workflow can run with AI switched off — the engines do not depend on it.
One call to understand the workflow, one week to write the spec and the golden cases, and a fixed proposal for the first release.