Platform
From a typed sentence to a filed return
One conversational surface for the person who did the work, one review surface for the accountant, and a single double-entry general ledger beneath both.
The write path
How a sentence becomes a posting
The write path is identical everywhere in the product, whether the input arrived by chat, by a messaging app, or as a photograph of a supplier bill.
The user describes what happened
In their own language, in their own words. No account codes, no tax codes, no form to navigate.
Intent and entities are resolved
The system determines the transaction type, the counterparty, the items, the currency and the applicable tax treatment, and links them to existing master data.
A posting is proposed, not made
A confirmation card shows the entry in plain language and in debits and credits, with the tax split, the source and a confidence score.
A person confirms
Until this point nothing exists in the ledger. A no discards the proposal and the conversation continues.
The entry is committed
Journal, sub-ledgers, tax positions and running balances are written in one transaction, with balance enforced at the database level.
Capabilities
What the platform does today
Live in the product and exercised against real client workloads rather than test fixtures.
Conversational bookkeeping
Any transaction, written as an ordinary sentence, over app chat or a messaging app, with durable memory of the conversation and the client's chart of accounts.
Invoicing and credit notes
Tax-compliant invoices, credit notes and statements generated from the ledger and the entity's template set. Numbering stays intact when a document is cancelled.
Document capture
Supplier bills, receipts and bank statements. Digital signatures are verified first, digital PDFs are read as text, then structurally parsed, with vision models as the final tier.
Indirect tax
VAT, GST and sales tax determination at the point of capture, periodic and annual returns, and nil filings, with date-effective rules per jurisdiction.
Bank and supplier reconciliation
Ledger entries matched against bank feeds and supplier records. Breaks are surfaced as exceptions, grouped by cause, with the source named.
Financial statements
Trial balance, profit and loss, balance sheet and cash flow, generated from the same ledger the daily conversation writes to.
Receivables and payables
What is outstanding, how long it has been outstanding, and what is owed to whom, without anyone maintaining a separate spreadsheet.
Audit trail
Every entry carries who or what created it, the evidence it was based on, its confidence score and a reversal path, retained for the life of the record.
Messaging as a first-class channel
The full capture flow works over a messaging app, because that is where the user already is. Invoices are delivered on the same channel.
Global by design
Multi-entity, multi-currency, multi-jurisdiction
A group is not a collection of separate books. Entities, currencies and tax regimes are first-class in the data model rather than bolted on for an international edition.
Entities and consolidation
Each legal entity keeps its own ledger, functional currency and tax registrations, with intercompany balances tracked and a consolidated view across the group.
Currency and revaluation
Transactions post in the currency they occurred in. Rates are stored with the entry, and period-end revaluation is a posting like any other.
Reporting frameworks
IFRS and local GAAP presentation from the same underlying ledger, so a statutory pack and a management pack do not require two sets of books.
Indirect tax regimes
VAT, GST and sales tax handled as configured regimes with their own rates, place-of-supply logic, return periods and filing formats.
Date-effective rules
A rate change or a rule change takes effect on its date. Restating a prior period computes it with the rules that applied then, not the ones in force today.
Fiscal calendars
Year ends, period locks and filing deadlines are configured per entity, so a group with mixed year ends does not need a workaround.
Language
One operating language per entity, chosen deliberately
Each entity picks one language and the entire product follows it. Interface, assistant replies, error messages and generated documents all move together.
Adding a language is not a translation file. It means an accounting and tax vocabulary that actually works, and a document renderer that sets the script correctly. We would rather do a few properly than many badly.
Free text, not fields
Understanding of typed input, including the code-mixed sentences people actually send from a phone, mixing scripts and languages inside one line.
Through to the document
The chosen language carries all the way to the invoice and the statement, with the script set correctly rather than transliterated.
English for correspondence
The default for accountants, auditors and formal correspondence, available alongside the operating language.
Accounting vocabulary
Each language ships with the working terms of accounting and tax in that market, not a generic dictionary.
Assistant and errors too
Replies, prompts and error messages are written in the same language, so the product never switches under the user.
Added one at a time
New languages are sequenced by where paying customers are, and each is validated with practising accountants before release.
Architecture
The architecture, briefly
Written for the people your team will ask before they sign.
Backend
Python and FastAPI, asynchronous throughout, with SQLAlchemy and Alembic managing a versioned schema.
Data
PostgreSQL with tenant isolation enforced at the schema level and asserted at application startup rather than trusted by convention.
Work queue
Celery over RabbitMQ, with Redis for cache and coordination. Long-running document extraction never blocks a conversation.
Agents
LangGraph orchestration over a configurable model provider, so a model can be swapped without touching accounting logic.
Interfaces
Next.js applications for the business, the accounting firm and internal operations, behind an API gateway that terminates TLS.
Observability
OpenTelemetry tracing, Prometheus metrics, Grafana dashboards and error tracking, because a system of record must be able to explain a bad day.
Put a real transaction through it
The fastest way to judge this is to type one sentence and look at the journal entry that comes out.