Every cent, recorded twice

Underneath every lending platform is a question that sounds too simple to ask: where is the money, exactly, right now? A surprising amount of financial software answers it with a single running balance — one number, updated in place, with the history of how it got there scattered across logs. SQF answers it the way banks have answered it for five centuries: with a double-entry ledger, kept to a discipline that software makes enforceable rather than merely customary.

Two sides to every movement

On SQF, every movement of money is recorded twice — once for where it came from, once for where it went. The two sides must balance, per currency, to the cent. An entry that does not balance is not flagged for review or posted provisionally: it is refused outright. The book cannot be made inconsistent, because the inconsistent posting never enters it.

Amounts are held as whole cents in exact integer arithmetic. There is no floating point anywhere in the ledger, and therefore no rounding drift — none of the fractional residue that accumulates when currency is handled as approximate decimals and reconciled away later. A cent is a cent, and sums of cents are exact, at any scale and in any currency the book carries.

Here is the shape of it in one worked example. Advancing RM 8,000 to a client writes two entries in one transaction: Bank, minus 8,000; Receivable, plus 8,000. The money's origin and destination are both on the record, the transaction balances by construction, and any posting that fails to balance to the cent is rejected before it touches the book.

Nothing is edited, nothing is deleted

The second discipline is as old as the first: the book is append-only. No entry is ever edited or deleted. A mistake is corrected by a reversing entry — a new transaction that undoes the old one and says so — leaving the mistake, the correction, and the link between them all on the record. An auditor reading the book sees what happened, including what went wrong and how it was put right, not a tidied version with the history rubbed out.

This is what evidence means in accounting. A ledger that can be edited is a narrative; a ledger that can only be added to is a record. When a regulator, an auditor or a funder's own risk committee asks what the position was on a given date, the answer is not reconstructed from backups — it is simply read, because nothing that was ever true has been overwritten.

The whole book proves itself on demand. A trial balance re-computes every account and confirms that the entire ledger sums to zero, per currency, at any moment — not as a month-end ritual but as a check that can run whenever anyone cares to ask. A book that balances by construction, and re-proves that balance on request, is the foundation everything else stands on.

Standards at the edges

A ledger is only as trustworthy as what crosses its boundary, so the edges are held to international banking standards rather than invented formats.

Payments leave as ISO 20022 pain.001 files — the structured payment-initiation standard banks themselves exchange — and the bank's acknowledgement is tracked per payment. If the bank rejects a payment, the rejection reopens the original request: nothing has been posted, so nothing needs unwinding, and nothing is lost. The ledger records money that moved, never money that was merely intended to move.

Invoices follow the UBL 2.5 structure, with totals computed from lines so the arithmetic cannot drift from the detail. Bank statements arrive as MT940 files and are checked to the cent before anything is accepted: the opening balance plus every line must equal the closing balance, or the whole statement is refused. A statement that does not sum is not partially trusted — it is not trusted at all.

Four eyes, enforced by the software

The controls around the ledger are enforced in code, not in policy documents. The person who prepares a payment can never approve it. The software refuses — even for administrators, even for the most senior role on the system. There is no override, because a control with an override for busy days is a suggestion.

Larger payments demand more approvers, at thresholds each funder sets for itself: a routine disbursement may need one signature, a large one two or more, each from a different person, none of them the preparer. And each approval requires a fresh six-digit code from the approver's authenticator device, so an unattended session cannot approve anything — the approval is bound to a person present at that moment, not to a login left open.

Why this is the foundation

None of this is exotic. Double entry, append-only records, exact arithmetic, standard formats, segregation of duties — every element is textbook banking practice. What is uncommon is holding software to all of it without exception: no edit paths for convenience, no floating point for expedience, no approval shortcuts for administrators.

We hold the line because everything else the platform does stands on it. The AI analysts, the knowledge graph, the funding pools, the treasury view — all of it ultimately reads from, or writes to, this book. A platform can be forgiven rough edges in many places. Its answer to "where is the money, exactly, right now" is not one of them. On SQF that answer is always the same: in the ledger, on both sides of every entry, provable to the cent.