Trust
We’d rather tell you what is true.
Every claim on this page is something the architecture actually does — enforced in the database, where an interface cannot route around it. Where we hold nothing, we say so, on the same page, in the same size type.
Enforced below the application
- Double-entry postingBalanced to the cent, checked against the open period.
- Multi-companySeparate books, one group view, row-level security throughout.
- Multi-currencyPer-transaction FX, realised and unrealised, revalued at period end.
- Fiscal calendarPeriod open and close, year-end close, and locks that hold.
Permissions & audit
Stand in somebody else's role
One supplier bill, five people. Change who is looking and watch what disappears, what becomes possible and what the engine refuses — while the audit trail beside it records every one of those decisions, including the refusals.
Signed in as Owner. Everything, including reopening a locked period. There is no higher level — not even us.
- Document date
- 18 Sep 2025
- Total
- €120,170
- Supplier bank account
- NL91 ABNA 0417 1643 00
Coding
Actions
Try one that is greyed out — the refusal is recorded too, with its reason.
Document created09:41 · Clerk
BILL-4471 · Nord Components BV · €120,170
Receipt attached09:48 · Clerk
nord-components-24118.pdf · 214 KB
Coding proposed09:55 · Engine
Matched to purchase order PO-1188 · two-way match
Entries are written by database triggers. Nothing here can be edited or removed — a correction is a new entry pointing at the old one.
This is a simplified illustration of the real model. In the product there are six roles — the sixth, admin, sits between owner and accountant and cannot reopen a locked period — and permissions are applied per company, so somebody can be an accountant in one entity and a viewer in another.
How it holds
Where each of these is actually enforced
Open any of them. Each is a property of the database rather than a policy someone has written down.
Every business row belongs to a company, and row-level security in the database decides who may read or write it. A user sees the companies they are a member of and nothing else — enforced below the application, not inside it.
- Row-level security policies on every table
- Company membership determines visibility
- Enforced in Postgres, not in application code
- The service key is used only for administrative jobs, never for request-path reads
Write access is decided by role, per company. Somebody who can enter a document cannot necessarily approve it, and somebody who can view the numbers cannot necessarily change them.
- Six roles with distinct write policies
- Permissions apply per company, not per account
- Role checks live in the same policies as the data
Approval rules run by module, document type and amount threshold. The submitter of a document can never be its approver — that constraint is in the database, so no interface can route around it.
- Rules per document type with amount thresholds
- Submitter and approver can never be the same person
- Every approval and rejection written to the audit trail
Once a document posts, it is immutable. Corrections flow through reversals and credit notes, and database triggers record who changed what on every business document. There is no administrative override.
- Immutable posted documents
- Corrections by reversal and credit note, never by edit
- Change history written by database triggers
- Failed operations and rule breaches logged as exceptions
Posting validates the period before it touches the ledger. Closed periods block posting; locked periods block everything, including reopening without an owner. Year-end close rolls profit and loss into retained earnings.
- Period status checked by the engine on every posting
- Locked periods cannot be reopened without owner rights
- Year-end close handled by the engine
Balanced debits and credits in base currency, postable accounts, an open period and the caller's role are all validated by database functions before anything is written. The application renders; it does not decide.
- Double-entry validated in the database
- Control accounts posted only through their subledger
- Money held as exact decimals — no floating point
Every list, report and enquiry exports. The schema is ordinary relational Postgres, not a proprietary store, so the data is readable without us.
- Export from any list, report or enquiry
- Standard relational schema, documented
- Attachments stored against the record and retrievable
G1 runs on managed Postgres with cookie-based authentication and company-scoped storage. Deliberately unremarkable technology, chosen because it is well understood and easy to leave.
- Managed Postgres as the system of record
- Cookie sessions refreshed server-side
- Company-scoped file storage policies
This list is content, not layout. When a control, a certification or an infrastructure commitment becomes true, it appears here with a date on it.
What we don't claim
Gallucci One does not hold SOC 2, ISO 27001 or any similar certification today, and we do not publish uptime figures or customer counts. When any of that changes it will appear here with a date on it. Until then, the claims on this page are limited to what the architecture actually does.
A vendor who will overstate a certification will overstate a delivery date. We would rather be the company that tells you the boring version first.
- No security certifications held today
- No published uptime or availability figures
- No customer numbers or named references yet
Ask us anything
Send us your security questionnaire. We will answer it honestly.
Including the questions where the honest answer is 'not yet'. You will know exactly what you are getting.