App family

Finance

Accounting foundations for a platform where every operational app can record money correctly: the chart of accounts as a tree, reporting dimensions as lenses rather than segment strings, tax codes, fiscal calendars and periods, exchange rates — and a journal that balances per entity per currency and is corrected only by reversal.

Who it's for

Written for the people who carry this

The CFO and financial controller

Operational systems each invent their own idea of an account and a cost centre. Mapping them to the ledger is a recurring project, and the audit trail stops at the export.

The finance systems lead

The general ledger is the system of record, but the sub-ledgers that feed it — assets, expenses, receivables — live in tools that have never heard of a fiscal period.

The apps

2 apps, one model underneath

Finance core◦ early access

The accounting foundations everything else posts against: the chart of accounts, the reporting dimensions, tax codes, fiscal calendars and periods, and exchange rates. It is not a general ledger application in itself — it is the master data and policy that lets any other app record money correctly.

Accounts · dimensions · tax codes · fiscal calendars and periods · exchange rates

Finance journal◦ early access

The general ledger: journal entries and their lines, and the posting rules that let other apps write to the ledger automatically. Entries balance per entity and per currency, and a posted entry is never edited — corrections are made by reversal, so the history stays true.

Journal entries · lines · posting rules

◦ Early access: in the catalogue now and installed for design partners first; general availability follows as partners put it to work.

How it connects. Connector apps map the operational registers to accounts: assets ↔ finance, expenses ↔ finance, trading partners ↔ finance. Each appears only when both sides are installed, and until it is configured the operational app works exactly as before but does not post.

Why one model

Any app can be a sub-ledger. The ledger stays honest.

Operational apps declare posting rules bound to their own lifecycles — an approved expense claim, a disposed asset — and post through the journal as a named source. Entries balance per entity and per currency; a posted entry is never edited, only reversed; periods are lifecycles; balances are always derived, never stored. What this family is not: a replacement for your general ledger today. It is the foundation that lets the rest of Zubl record money correctly, and it installs without the journal if all you need is the chart.

Not quite your shape?

Extend these apps, or build the one you need.

Every app here is open to extension on the same licence: a field, a lifecycle state, a link to a record in another family, a rule. Additions sit beside our definition and survive every upgrade.

And if the register your organisation needs is not here, describe it to the AI builder. It arrives governed — same access engine, same audit trail, same reports — because those belong to the platform, not to the app.

Extending and building →

We're working with design partners now.

A small number of organisations shaping the first release, in exchange for early access, direct influence over what ships next, and pricing that reflects the risk of going first.