Chronos Ledger

For a planning application today the obvious move is to build in a language model: a question in words, an answer in words. Chronos Ledger deliberately has none. A liquidity forecast becomes the basis for decisions about wages, purchases and tax reserves. For that, the same data has to produce the same figure on every run, and every figure has to be traceable to the bookings it came from. A question panel was on the table and was not built; it would have been the first outbound API call this application ever made.

The second decision carries the whole application. For every request the planning horizon is built exactly once as a flat list of dated rows: booked movements, expanded standing orders, payroll runs, the derived VAT and profit tax payments, cleared investments and expected income tax refunds. Every chart and every table is computed from that one list. Two views are never supposed to disagree about the same day. When the header and the curve once did, because two functions walked the same rows separately, the audit script found the difference.

The third concerns tax. What a booking is, what the VAT return sees of it and what the profit calculation sees of it are three separate columns. A single type per booking cannot express a transfer between your own accounts, which moves money on two accounts and is revenue nowhere. Categories preset the three values, but every booking keeps its own copy.

What deliberately does not come out of this is a tax return. The application projects and prepares; it transmits nothing to ELSTER, and every tax view carries the note that it is an estimate.

A forecast that cannot be recomputed is an opinion with decimal places.

A self-test locks the arithmetic: money amounts, deadlines with their shifts, VAT, profit taxes, the zones of the income tax tariff, series, adjustment rows and the uncertainty band. Anyone changing a rate or a tariff constant changes the matching assertion in the same step. A silent constant change is exactly the failure this application cannot absorb.

An audit script recomputes the central totals a second time straight from the raw tables, with its own code: liquidity today, low point, end of horizon, VAT and profit base. It also reports bookings that contradict themselves, such as an outflow classed as revenue. Where the disagreements came from was instructive: more than once the fault lay in the audit script, because it did not yet know a rule the engine already had. Since then every new rule comes with the question of whether the audit script knows it.

And the application records its own forecasts: once a day, month ends only, never overwritten. Later they are scored against what the accounts actually held on booked movements, never against a newer forecast. The error is averaged as an absolute value, so that one figure too high and one too low do not cancel each other out.