One posting engine.

Everything in the ledger passes through one posting engine, and that single point of control is what makes the rest of the system trustworthy. The engine validates and posts invoices, payments and journals, reposts a withdrawn transaction, deletes and allocates, and it is the only code in the application that writes a ledger row. It works to the conventions of the existing ledger: a debit is a negative base amount, the header is always journal line one, and dates are held as legacy eight-character strings parsed through a single reader instead of being cast at each site.

Invoicing runs on one surface for both the payable and receivable sides, through a four-step rail of header, lines, review and payment. Credit notes, foreign currency, line-level business analysis and attached documents are available throughout. The sign of every line comes from one formula, and the debit or credit letter is derived from the resulting amount instead of being passed alongside it, so the two can never disagree.

Payments follow how finance teams actually settle:

• Paying from an invoice posts the invoice and then the money. If the second step fails, the first is rolled back newest-first, because each engine opens its own connection and a single database transaction is not available across them.
• A part payment posts on account; only an exact settlement allocates.
• An amount above the outstanding balance is refused outright, and the server refuses it independently of the browser.

Banking covers statement import across four bank layouts, with the format detected from the file itself, and a reconciliation sheet that arms only when both sides of a proposed match net to exactly zero. A statement line can be processed directly into a new payment or invoice through the same posting engine; there is no parallel path.

Three further controls complete the core:

• Open periods are enforced at three levels (entity ledger, module and account), and a refusal always names the level that blocked the posting.
• Multi-currency uses European Central Bank reference rates with no API key, nine decimal places of rate precision, and one shared arithmetic module used by both the browser and the posting engine.
• Amendments to a posted transaction are limited to named non-financial fields, one at a time, through a fixed key map: an unrecognised key is refused and no column name ever travels over the wire. A full reopen goes through a read-only gate that answers whether the transaction may be reopened and, if not, which allocation, reconciliation, period or filed return stands in the way.