Technology
For the people who want to know what is underneath.
Deliberately unremarkable technology, used carefully. Relational Postgres, a double-entry engine that lives in the database, permissions below the application, and exact decimal money. The interesting part is not the stack — it is that there is no way around any of it.
38 modules and 52 connectors sit on one engine, one permission model and one data layer. Adding another is configuration.
The engine
The life of a transaction
Everything G1 claims about integrity is really a claim about this path. Follow a supplier bill from the moment it turns up to the moment it changes a number on a report — and back again.
Stage 01 / 06
A document turns up
A supplier bill, a customer invoice, an expense claim, a card statement line. It is keyed, imported from a file, or attached from an email — and at this point it has not touched the ledger at all.
- File imports are staged and validated row by row before anything commits
- The attachment stays on the record, retrievable from the journal later
- Nothing about it is an accounting fact yet
The same path runs for an invoice, a receipt, a depreciation run, a payroll journal and a card statement line. One engine, one audit trail, one set of rules — which is why a subledger and its control account cannot drift apart.
What it is built on
Sophistication, without trying to prove sophistication
No jargon wall. These are the parts of G1 a technical reader will want to check, described the way we would describe them to each other.
Modular architecture
Modules share one engine, one permission model and one data layer. Activating one does not require the others, and adding one does not disturb what already runs.
- Shared engine, independent modules
- Activate what the business needs, when it needs it
- A new module is an addition, not a migration
Data layer
Relational Postgres with an explicit schema. Every business row carries its company, every amount is an exact decimal, and every transaction carries its own currency and rate alongside the base-currency figures.
- Company on every row, enforced by policy
- Exact decimal money — no floating point
- Transaction and base currency stored together
Posting engine
The only thing that can write to the ledger.
- Balanced debits and credits, validated in base currency
- Period and postability checked before writing
Permissions
Row-level security and roles, below the application.
- Row-level security on every table
- Role-based write policies per company
Automation
Rules and schedules that run without supervision, within limits people set.
- Schedules that materialise their own entries
- Matching that suggests rather than silently posts
Integrations
File import with row-level validation and a staged commit, export from every list and report, and a connector library designed to grow. What exists today is stated honestly on the integrations page.
- Staged imports validated row by row before commit
- Export from anywhere you can see data
- Connectors added as content, not as releases
Analytics
Reporting and analysis read the same records the ledger writes. Every figure drills through to the journal line and the source document behind it.
- One definition per measure
- Dimension filters throughout
- Drill-through from any figure to its source
AI
An integrated layer, bound by the same permissions.
- Scoped to the user's own permissions
- Answers cite the records they came from
Auditability
Nothing disappears, and nothing can be quietly changed.
- Immutable posted records
- Trigger-written change history
Scalability
More companies, more currencies, more sites — as configuration.
- Multi-company and multi-currency from the first entry
- Shared chart of accounts and dimension structure
APIs
A permissioned API over the same data model, plus webhooks for business events. Not built yet; it is on the roadmap and listed in the integration library as planned.
- Same data model as the application
- Bound by the same row-level security
- Webhooks for posted, approved and matched events
Engine guarantees
6 things that are true of every module
Not features you switch on. They are properties of the engine, so anything that posts inherits them.
Double-entry posting
Every transaction posts balanced debits and credits, validated against the open period before it touches the ledger.
Multi-company
Separate books per company, with row-level security on every table so people only ever see the companies they belong to.
Multi-currency
Per-transaction FX with realised and unrealised gains, plus revaluation runs at period end.
Fiscal calendar
Period open and close, year-end close, and locks that actually hold — accrual and cash-basis reporting side by side.
Maker-checker
Approvals are enforced by role, and the submitter of a document can never be its own approver.
Immutable audit trail
Posted documents cannot be edited. Corrections flow through reversals and credit notes, and triggers record who changed what.
Ask the hard questions
Technology should adapt to the business. Not the other way around.
If you want to interrogate the data model, the posting rules or the permission model, that is a conversation we enjoy.