What we are building

The problem this is aimed at

Most of what happens in a practice at close-time is not calculation. It is reconciliation of belief. A partner sits with a workpaper file and asks a preparer: where did this come from, why did we take this position, and if the regulator asks in three years, will we still know? The answers live in a mix of email chains, shared drives, mental models, and the preparer's memory. Under load, they degrade.

The tools that were meant to solve this — workpaper platforms, review checklists, practice management — each solve a slice. None of them make the underlying chain of reasoning a first-class object that can be inspected, replayed, and audited. When a review question comes in from the ATO, HMRC, or an insurer three years after the fact, the chain is reconstructed by hand, or it isn't reconstructed at all.

LodgeiT Labs is building the substrate that makes the chain first-class. The wedge is accounting and tax, because that is where mathematical closure exists — double-entry algebra, statutory law, and the disclosure taxonomy behind iXBRL are all domains where proof is resolvable. Everything else in the platform extends outward from that wedge.

This post walks the whole stack, from the statutory reasoning layer up to what a professional's day looks like once they adopt it. It is deliberately non-technical where it can be. Where it has to be technical, it names the thing and moves on.

The three layers, and why they are separated

Every component in the platform sits in one of three concentric layers, and the separation is load-bearing:

• The Deterministic Core. Double-entry algebra, the SBRM disclosure manifold, statutory constraints, provenance hashes. This layer is not allowed to be wrong without being auditably wrong — every failure surfaces as an exception you can point at.
• The Probabilistic Ring. Machine-learning classifiers, natural-language reasoners, transaction categorisers, entity recognisers. This layer is allowed to be uncertain, and its outputs always carry a calibrated confidence and a witness — never authority.
• The Semantic Membrane. The way the system speaks — to accountants, to regulators, to other software, to auditors reading the trace years later. Controlled natural language, disclosure renderings, review artefacts, correspondence surfaces.

This is what makes the platform genuinely different from a tool that bolts an LLM onto an existing GL. In our stack, the AI is never the source of truth — it is a proposer that has to survive a deterministic firewall before its output ever touches a general ledger. When it survives, the reasoning is legible. When it doesn't, the rejection is explicit and typed.

Layer one — statutory reasoning in the language you already speak

Statutes are prose. Software is code. The gap between them is where most tax-technology projects break down: they either force the accountant to trust an opaque calculator, or they force the developer to hand-encode statutes into procedural code that nobody but the developer can audit.

We use Logical English — a controlled natural language originally developed within the LogicalContracts research programme — as the middle ground. Statutes are expressed in sentences a tax professional can read, and those sentences compile directly into deterministic logic that a reasoning engine can execute. When Div 7A fires on a shareholder loan, or when a UK company qualifies as small under s382 Companies Act 2006, the rule that made it fire is a paragraph of English you can point at, not a black box.

Every assertion at this layer carries a trust tier: verified against primary statute, verified against precedent, community-ratified, or provisional. When two tiers disagree — a provisional rule contradicting a precedent-verified one, for example — a disagreement detector fires and the conflict becomes visible before it can propagate downstream.

What this means for a practitioner: the software's tax reasoning is not a trade secret. It is a document. You can review it the way you would review a technical memo, and you can update it the way you would update a checklist when the law changes.

Layer two — the semantic backbone that anchors every line item

Most classification tools ask a shallow question: what account does this transaction post to? That is a category error. The question underneath is what does this line item mean? — because the same real-world event can post to different accounts under different jurisdictions, different frameworks, and different firm-level charts.

Our semantic backbone is a canonical address space. Every line item, every trial-balance row, every calculator output, resolves to a semantic address before anything else in the system reasons about it. The classifier that produces those addresses runs continuously against production data and is retrained on a disciplined cadence; the current substrate has stabilised at accuracy plateaus where architectural improvements matter more than additional training volume.

The important discipline: the classifier is always a proposer. It never writes to a ledger. A semantic-address prediction is a proposal that has to survive downstream constraints before it becomes an approved posting. When the classifier is 98% confident, the deterministic core still checks it. When the classifier is 60% confident, the same check runs — the difference is only how visible the review artefact is to the operator.

What this means for a practitioner: automated coding stops being a matter of trust. You get to see why the system proposed a particular treatment, at the semantic layer, and you get to accept or reject with a witness that survives into the audit trail.

Layer three — the calculator constellation

Rather than building a single monolithic tax engine, we build a constellation of deterministic calculators, each responsible for a bounded statutory domain:

• Depreciation (prime-cost, diminishing-value, low-value-pool, IAWO, general-pool restatement)
• Division 7A (loans, minimum yearly repayments, deemed dividend calculations, benchmark rates)
• Hire purchase (interest apportionment, principal reconciliation, GST timing)
• Fringe Benefits Tax (calculation, deemed depreciation of benefits, reportable fringe benefits)
• UK Corporation Tax (CT600 computation, iXBRL rendering, HMRC transport)
• Companies House filings (AA02 dormant, FRS 102 1A small/micro, iXBRL against the current FRC taxonomy)
• Transfer pricing (Subdiv 815-B, IDS, CbC, DTA, DPT, thin cap, TNMM, DEMPE, TR 2024/D1)
• VAT (MTD-compliant lodgement)

Each calculator is a small, deterministic engine. It takes structured inputs, produces structured findings, and carries its own witness — the specific rule chain that led from input to output, expressed at the statutory-reasoning layer where a professional can inspect it.

Statutory rates and thresholds are not hard-coded. They live in period-scoped rate tables that are updated as legislation moves, and the calculator asks the table at run-time. This is a small thing that matters enormously in practice — when the ATO revises a rate, or the Chancellor announces a threshold change, the calculator does not need to be rebuilt. The rate table does.

Layer four — SBRM as financial-truth manifold

Charles Hoffman's Standard Business Reporting Model is not a reporting format. It is a closed algebra of financial assertions — a mathematical object over which double-entry is a homomorphism, over which UK and AU tax law can be projected as constraint sets, and over which auditors can walk provenance chains without hallucination.

Every trial balance, every journal, every disclosure, every workpaper in our stack is an element of this manifold. The consequence is quiet but powerful: the same underlying facts can be projected into any framework — FRS 105, FRS 102 1A, IFRS, an ATO-recognisable general-purpose financial report — without re-keying, and with the transformations themselves recorded as first-class witnesses.

The Seattle Method — Hoffman's codification of disclosure mechanics, reporting checklists, and the reporting-style discipline that turns algebra into a legally defensible artefact — is the layer above SBRM that most competing platforms don't build. It is what closes the loop between the numbers are right and the report is defensible.

Layer five — agentic controls, with real firewalls

Every serious practitioner has seen the same demo now: an AI assistant that suggests a journal, an accountant clicks approve, and the journal posts. It looks impressive. It is architecturally a disaster.

The failure mode is not that the AI proposed a wrong journal — it will, sometimes, and that is fine if the perimeter catches it. The failure mode is that there is no perimeter. The approval click is a rubber stamp because the operator can't see what actually changes on the balance sheet and P&L before they approve.

Our agentic layer has two hard firewalls, and no agent bypass exists:

• Semantic firewall. Every calculator-originated journal is checked at emission against a seven-way polarity taxonomy — current asset, non-current asset, current liability, non-current liability, equity, income, expense. Topologically invalid postings are rejected before they reach the GL staging layer. Rejections are not silent booleans; they are typed artefacts with witnesses.
• Structural firewall at the GL boundary. Every journal, whether calculator-originated or human-authored, passes a structural check: debits balance credits, polarity tags are present, accounts exist, periods are open, source attribution is complete. Manual journals authored at the GL interface still traverse this firewall.

Above the firewalls sits an async staging boundary. Calculator-originated journals never post synchronously. They become review artefacts, each carrying a dry-run diff that shows the operator what changes in the balance sheet, P&L, cash flow, and equity statements before approval. The load-bearing UX element is the diff. Black-box AI journals are the failure mode this design forecloses.

What close-time becomes

Here is where the whole design converges on something new.

A period close, in most practices today, is a workflow. A checklist is worked through, a reviewer signs off, a file is finalised, and the underlying reasoning — why particular treatments were adopted, which rules fired, what evidence was consulted — is captured in whatever ad-hoc notes the preparer had time to leave.

In our substrate, a period close is a settlement event. When the close signs, every journal in the period becomes immutable and hash-bound. Every journal points at its source: for calculator-originated postings, the calculator and the specific finding; for manual postings, the operator identifier and the approval signature. Every finding points at its witness. Every witness points at the rule chain that produced it. Every rule chain terminates in either statute — verified at the trust tier its consumer requires — or double-entry algebra.

The audit trail is not generated at close-time. It is the substrate the close ran on.

The consequences ripple outward:

• Partner review time collapses. Not because the AI is doing more, but because the trace is legible. Review shifts from let me check the numbers to let me check the reasoning.
• Regulator submissions become deterministic. iXBRL is generated from the manifold, not from a template mapped over a spreadsheet. First-submission acceptance stops being aspirational.
• Insurance carriers can price professional-indemnity risk on visible evidence. That is a business consequence with significant downstream value.
• Cross-jurisdiction workpapers become composable. A UK close and an Australian close for related entities share provenance chains cleanly.
• Three years later, when a regulator asks, the answer takes minutes, not weeks. The chain is still there, still hashed, still cryptographically bound to the position the firm took.

The adoption arc — what your practice looks like month by month

How does a firm actually onboard? The path is intentionally gradual, because the substrate has to earn trust incrementally. The following is what the arc looks like from a partner's chair.

Day zero — first contact

The interface you and your team see is the LodgeiT commercial product surface you already know. Jobs. Work objects. Rules. Issues. Approvals. Familiar vocabulary. The substrate underneath is invisible to the practitioner.

Week one to four — ambient ingestion

The system begins consuming artefacts — bank statements, invoices, prior workpapers, trial balances — and surfaces findings as proposals against your existing work items. Each proposal carries a natural-language justification you can read. You accept, reject, or request changes. Every interaction trains the system's model of how your firm wants to work.

Month two — the calculator constellation engages

A Div 7A scenario surfaces, or a depreciation restatement, or a Companies House filing comes due. The relevant calculator fires. You see a staged journal batch with a dry-run diff of what changes in the balance sheet and P&L. You approve, reject, or request changes. The critical moment: you see what changes before you approve. Black-box AI journals disappear from your workflow because they are architecturally impossible.

Month two to three — first close

You run a period close inside the substrate. You watch the settlement event fire. Every journal has its provenance chain. The audit report generates itself from the trace, not from a template. The realisation, at this point, is that the audit is the substrate, not a deliverable produced afterwards.

Month three — first regulator submission

You lodge to Companies House, HMRC, or the ATO. The iXBRL is generated deterministically from the manifold. It passes on first submission, because the provenance chain is deterministic and the disclosure mechanics were checked at close-time rather than after the fact.

Month four and beyond — the discovery

You notice review time has collapsed. Not because AI is doing more, but because the trace is legible. Partner review is now check the reasoning, not check the numbers. You start referring the substrate to your clients as a compliance moat — the phrase that comes up in your business-development conversations changes.

Month six and beyond — the extension

Adjacent domains start to become visible. The same substrate that carried tax reasoning can carry ESG reporting, transfer pricing, restructuring, sector-specific disclosure. You stop thinking about the platform as an accounting tool and start thinking about it as your firm's reasoning substrate. That mental shift is the adoption inflection point.

What we are — and what we are not

We are open-source infrastructure. The core reasoning engine, the calculator constellation, the SBRM manifold, and the statutory-reasoning layer are all developed in the open, under permissive licences, in the lodgeit-labs GitHub organisation. Firms and individuals are welcome to inspect the code, run it, extend it, and build on top of it.

We are not replacing your practice-management, your client-facing portal, your ATO/HMRC-agent credentials, or your professional judgement. Those remain with the firm and the individual. Where the LodgeiT commercial platform provides the practitioner surface, this substrate sits underneath it as the reasoning layer.

We are not a general-purpose AI assistant. The system does one thing very well — produce provenance-chained, statutorily-anchored financial reasoning that survives audit — and its scope is deliberately kept bounded to that.

We are not asking you to trust a black box. Everything the system does is inspectable. Every rule that fires is a paragraph you can read. Every classifier decision carries a witness. Every calculator finding points at its statutory basis. If the substrate is ever wrong, it is auditably wrong — and that is the design promise the whole architecture is oriented around.

Where the wedge extends next

Accounting and tax are the wedge because that is where proof is resolvable today. The disclosure manifold, the trust-tiered statutory reasoning, and the async operator-approval boundary are all general architectural moves — they extend cleanly into any domain where deterministic constraints and probabilistic reasoning need to be composed under audit.

Sustainability reporting, transfer pricing under increasing regulatory pressure, insurance underwriting, professional-indemnity risk pricing, and cross-border regulatory harmonisation are all downstream of the same substrate. We are building the accounting and tax hyperplanes first because that is where the algebra closes cleanly. Everything else follows from what gets proven here.

How to engage

If you are a practitioner and you'd like to see the substrate in operation, the primary path is through the LodgeiT commercial platform, where the reasoning layer described in this post is progressively becoming available beneath the interface you already use. The commercial site is the front door.

If you are a developer or a firm-level architect, the GitHub organisation is the technical entry point. The calculators, the reasoning engine, the SBRM tooling, and the disclosure bridges are all there, along with the specifications that govern how they interoperate.

If you are a professional body, a regulator, or an insurer interested in the audit-substrate implications of what we are building, get in touch through the commercial channel and we'll route the conversation appropriately.

We are, architecturally, ready to ship. What comes next is a matter of finding the practitioners who want to build the next few years of the profession on a substrate that doesn't lie.

---

Written for accounting and tax professionals. Comments and corrections are welcome via the GitHub organisation. Follow the blog for further notes from the substrate.