No story about AI. The actual chain, line by line.
What runs at night, where the amounts come from, which rules decide whether a question arises, what the gates stop and why we went that way at every fork. Every number on this page was taken from the running machines on 17-09-2026.
in-house, no cloud
the full back office, rebuilt every night
measured live, no mock-ups
Four roles in-house. No cloud, no external inference.
Schedules, stores and orchestrates. Deliberately runs no language model.
Carries the knowledge layer and the largest language models.
Reads the document stream in parallel and does the text recognition.
Holds the archive and the backups. Always source, never target.
Each role on its own machine. One machine may fail without the others stopping, and what stores does not compute, what computes does not store.
One machine blocks ping. We used ping as a presence check and got a false outage. The check belongs on the service port, not the protocol. That is now a lesson in the register.
Measured on our own machines, 17-09-2026.
Every phase proves itself before the next one starts.
One orchestrator. Every phase logs four numbers, source, processed, errors, status, and writes its own partial log. A non-critical phase may fail, reports it, and the chain continues on the previous value. Only the phases every amount depends on can stop the chain.
If the document scan fails, yesterday's index stays and the chain continues. If the restore or the ETL fails, everything stops. That distinction is in code per phase, it is not improvised at night.
Duration measured over 31 runs before versus 14 runs after the change of 03-09.
Every amount is one SQL sum. No model touches a number.
One measurement core that adds up revenue, cost and result per client, per contract group, per object and per period. The outcome is the gap against the norm. A model then phrases the sentence, but the amount is already calculated and re-checked.
The gap is norm times revenue minus result. The key is never the debtor code alone but debtor code plus administration. Every join always runs on year and administration. Those are three working rules, not software.
One client can exist in several administrations at once. Deduplicating on debtor code alone throws whole companies away. Without the administration in the key, the contract dimension yields 13,233 rows on 10,334 contracts. We made that mistake once and then fixed it as a hard rule.
Every contract group has its own norm. Glass and floors run differently from cleaning, regie work should cover cost, and sickness counts in the wage norm. A generic margin norm across everything produced 26 of 38 false signals in our own audit. That refinement is sector knowledge, not a parameter. The norms themselves belong to the company and are not on this page.
We asked for a closing date. There is none.
We asked the back office for a fixed closing date per period. The answer was a counter-question, what do you mean by closing, our periods are never closed. That turned out to be measurably true, and it forced the most important part of the system.
| period | ended | invoiced after period end | last booking |
|---|---|---|---|
| P1 | 28-01-2026 | 51.6 % | 14-08-2026 |
| P2 | 25-02-2026 | 44.3 % | 14-08-2026 |
| P3 | 25-03-2026 | 42.6 % | 21-08-2026 |
| P8 | 12-08-2026 | 5.5 % | 27-08-2026 |
The first period of the year ended on 28 January and kept growing for seven more months. More than half of that period's revenue was booked after the period ended. Closed is not a state that arrives, it is an asymptote. A system waiting for a closing email waits forever, and a system that trusts the calendar asks questions about figures that are not finished.
A period may only count from the back office's ready day, measured consistently 32 days after period end. This is a company parameter, every company closes differently and it is one of the four things re-established per connection.
If a draft or a pending invoice is still open for that client and that period, it is not ready, whatever the calendar says.
If this client materially booked after its ready day in earlier periods, it gets four extra weeks. For P5 that was 80 known late bookers from P1 to P4.
Cost-ripe and invoicing-ripe do not run in step. On 17-09 the portfolio was cost-ripe through P8 and invoicing-ripe through P6. The window is also per client, not portfolio-wide.
Backtest over P3 to P5, material from 5,000 euro. Rule set on 10-09-2026, measured before it was deployed.
Twenty-five card types, walked in a fixed order.
A client can have an invoicing problem, an absence problem and a rate problem at the same time. The ladder runs from hard and explainable to soft and interpretable. The first type that closes wins, the rest stays on the card as fact, but does not become the question.
- 01terminationclient or object stopped, costs continue. Hardest, because the end date is in a document
- 02creditingcredit notes net over the whole series, not per item
- 03invoicingdraft invoices and completed work orders that have not gone out yet
- 04rechargingpurchased work without covering revenue on the same contract
- 05allocationrevenue or cost booked on the wrong contract or object
- 06scopethe work was reduced or moved, contract continues
- 07sicknessabsence above the norm, replaced or not, recharged or not
- 08ratesoftest, because this only becomes the question once every other explanation is gone
- 09smallbelow the big threshold but above 500 euro, one point to steer on
- –silentchecked and healthy. 503 of 639 monitored client files on 17-09. Silent is an outcome, not an absence
Every card type comes with three possible explanations and the matching action, defined in advance. Not because the system knows which one is right, but because the recipient then sees at a glance what kind of answer is being asked. For rate, for instance, the rate does not cover the effort, or the effort is higher than agreed, or the contract can no longer be made to cover cost.
No signal without a contract basis. Without a contract the system does not know what was agreed, so no question comes out, however skewed the figure. That is the oldest rule in the system and it has saved us more often than any threshold.
Four gates. All four fail-closed.
A system that sends unchecked questions to managers every night is one bad run away from zero credibility. So four gates stand between the measurement and the human, and every gate stops on doubt instead of letting through.
Re-checks the card against its own text. Is the headline amount also in the facts? Is there exactly one question? Does the text mention a period outside the window? Is a mandatory field empty? Is the question itself measurable, something the system should have calculated instead of asked? One hit and the card goes into quarantine.
Every number in the written text must trace back to the measurement beneath it. A number the model invents does not survive the night. On 17-09 that counter stood at zero across 639 cards.
A card is a question with an offer to help, never an order. Imperatives are blocked. The destination duty lives here too, no signal without a recipient. A card without an owner lands on an owner-less list and is reported, it does not go blindly into the organisation.
May refine an amount, may never remove a card. Any error in the re-measurement leaves the original outcome standing and flags a measurement error. Fail-closed in both directions.
One client, six steps, from raw booking to one question.
Real client from the night of 17-09, name and amounts omitted.
Per contract group, per object and per period. Key is debtor code plus administration, window P1 through P8.
client as a whole 23.8 percent, healthy
| contract group | margin | norm | verdict |
|---|---|---|---|
| Cleaning | 14.4 % | below the norm | gap |
| Glass per month | 49.2 % | above the norm | silent |
| Glass per visit | 31.8 % | on the norm | silent |
| Miscellaneous | 100 % | above the norm | silent |
Glass per month and Miscellaneous run above their norm, Glass per visit sits on it. No question. What remains, cleaning below the norm. The client as a whole runs 23.8 percent and is called healthy in every summary. That is exactly what a total hides.
Not stopped, no credit notes, no open drafts or work orders, no third parties without cover, revenue on the right contract, revenue stable, absence below the norm. Seven explanations ruled out, only then rate.
- headline amount is also in the facts
- exactly one question on the card
- no period mentioned outside window P8
- type, fact, question and amount filled
- question is not something the system can measure itself
- recipient known, district manager and project manager found
Same night, other cards. A period mentioned outside the window. A question the system should have calculated itself. A rate question for a stopped client. A card without a recipient. Those go into quarantine with the reason attached and onto a list, not to a person.
started 03:15, done 04:44
Cleaning runs 14.4 percent over P1 through P8, below the norm for this contract group, while the client as a whole is healthy.
Does the cleaning rate still cover the effort, or should it be revised?
- a. rate does not cover the effort, propose a rate revision
- b. effort is higher than agreed, back to the contract
- c. can no longer be made to cover cost, wind down or terminate
owner project manager · 14 working days · escalation district manager above the threshold · source card per period
This client is one of 136 with a question, alongside 503 that were checked and healthy tonight and that the organisation hears nothing about.
What it reads, what it thinks about, and what comes out.
Measured on our own back office, night of 17-09. Names and amounts omitted, the reasoning is real.
- 01On Floors per visit there are costs without cover over P1 through P8.
- 02But 9 draft invoices are open, the oldest from late April.
- 03If those drafts go out, the shortfall disappears. So not a recharging question but an invoicing question.
Why are the drafts not yet final, and can they go out now for the work on Floors per visit?
owner project manager · escalation district manager · source card per period
- 01One regie contract carries costs and zero revenue in P2 through P8.
- 02The client itself runs 19.2 percent and went up 11.6 points. That is not the problem.
- 033 credit notes were re-invoiced within 45 days, net no crediting. What remains, the contract.
Was that work agreed as non-rechargeable, or should it still be recharged?
owner project manager · escalation district manager · source card per period
- 01All objects with revenue carry end date 30-04-2026 or are set to stopped in the source system.
- 02After that date there are still costs and a remnant of revenue in P6 through P8.
- 03Window therefore P1 through P4. A stopped client gets no question about periods that no longer exist.
The client stopped as of 30-04, but costs and revenue still appear after that date. Is that correct?
owner project manager · escalation district manager · source card per period
Three different types, the same route. Read from the source, reason until one explanation remains, and one question with amount, owner and deadline.
131 measurement flags, each one a decision someone once made.
The selector carries 131 named flags that can be switched on and off individually. Every flag has a number, a reason, a date and a GO. That is how a behaviour change can be reverted without touching the rest, and how you can see afterwards why the system does what it does.
A prompt is not testable, not versionable and not traceable. With the termination guarantee we proved that an instruction in a prompt alone is not enough for a critical fact, the model deviated as soon as the context changed. Hard rules have lived in code ever since, and code always beats the prompt.
The selector contains 57 notes that literally start with OWN MISTAKE, with the time and what went wrong. That is not tidy code style but it is why the same mistake is not made twice. Alongside it, a register of 61 numbered measurement lessons.
| example of a rule | what it enforces |
|---|---|
| 13 periods | never divide by 12, P13 can be five weeks |
| fixed revenue | measure on fixed revenue, not on total or extra |
| allocation booking separate | an allocation across locations makes the margin look better than it is |
| group by number | group names change per year, match on the number before the dash |
| invoice status draft | draft is not revenue, even if the source system says invoiced |
| credit notes net | over the whole series, not per note |
| relation type debtor | without that filter an employee name surfaces as a client name, GDPR risk |
Code fetches the facts. The model does the wording.
A language model makes mistakes, code does not. A sum is right or it is wrong, there is no judgement in it. So the model touches no fact at all. It receives the measurement ready-made and does what it is better at than we are, explaining what is going on in plain language, written so the right person understands it at once and can act on it.
Amounts, dates, keys, balances, periods, norms, thresholds. Deterministic. Same input always gives the same number, today and a year from now.
Which signal it becomes, which card type, who the recipient is, when to escalate. Explicit, testable, versionable.
The opening line, the explanation, the question and the offer to help. And the tone, because a district manager wants to read something different from a project manager. Fixed settings, always the same answer to the same measurement.
Then it is a sentence that reads badly. Not an amount that is wrong. That is a very different kind of error, and it is the only kind we have left.
On the same 59 fresh cards the best language-model variant scored 47 right and 3 wrong. The deterministic route scored 52 right and 0 wrong. The model did not win. So code calculates and the model writes, until a measurement proves otherwise.
When a better model arrives, the sentence gets better and nothing changes in the measurement, the rules or the gates. That is exactly why we dare to deliver this to more companies.
From ledger to tender, one picture per client.
The figures say what is happening, the documents say what was agreed. In every company those live in separate worlds, and that is where the day goes. We read both every night and hang them on the same client key.
| what is on the disk | count | where it lands on the card |
|---|---|---|
| Contracts, addenda, terminations | per client | termination, scope, rate |
| Indexation letters | 1,434 | rate and indexation |
| Collective invoicing, man-day registers | 1,217 | regie, invoicing, peak |
| Work-order overviews and corrections | 690 | invoicing |
| Credit invoicing, underlying documents | 272 | crediting, joinable on note number |
| Purchase invoice archive | 98,251 | third parties and recharging |
| Agency timesheets | 8,156 | hired-in staff and sickness |
| Quarterly management reports | 2,082 | recharging and scope |
| Tender desk, procurements and references | 85,039 | contract structure and new business |
| Payroll and personnel files | — | deliberately kept out, personal data |
The card that says a rate does not cover the effort points straight to the change form in which that effort was altered. Not as a reference but as a document, with date and path. Nobody has to search which system it was in again.
Of the 137 question cards of 15-09, 97 found a candidate record in the client's own folder. Change forms, specifications, indexation letters, terminations, with date and effective date taken from the file name.
34 of those 137 fail on group structure. One client folder covers several debtors. The source system does know that hierarchy. That is one link that closes this in one go.
In 68 percent of cases the client field in the knowledge layer holds a truncated client name instead of a real code. Measured across the whole knowledge layer. Exactly why the key has to come from the source system.
Full inventory measured on 15 and 16-09-2026, read-only.
Every architecture choice here was paid for with a measurement error.
This is the part you never see in a demo. Six choices, with the mistake that forced each one.
Not on principle but out of necessity. Personal data in contracts and absence files. Special categories are left out, not masked, because masking leaves the content in place and a person stays recognisable through role, location and date.
An export from yesterday that breaks halfway looks exactly like a complete export. A full restore of 11.6 GB is slower and is the only form in which you know for certain what you have.
A chain that continues after an error delivers a half truth that looks like a whole one in the morning. Error handling that logs and continues hides errors, one measurement layer failed for 76 nights that way while everything stayed green.
Source, processed, errors, status. Done without those four does not exist. Zero rows is never a conclusion but always a reason for a second measurement, because a wrong file pattern produces a false zero just as easily.
The document scan across 1,098,279 files no longer runs inside the chain. The storage runs it in its own time, the night chain collects the finished result and immediately starts the scan for the next night without waiting for it. That phase now takes minutes instead of hours. The cause was measured before we built anything, not the network but a cold metadata cache, so raising the timeout would have been a guess.
Agents may not send to people themselves. Everything goes through one door with a verification block. Otherwise, after six months you no longer know who sent what to whom, and that is exactly the moment an organisation loses trust.
Sources, 61 numbered measurement lessons in our own register plus 57 OWN MISTAKE notes in the selector.
The engine is generic. Only the keys and the norms belong to the company.
Debtors, projects, contracts, contract groups, hours, work orders, invoices. Anyone running a back office with that structure has most of the translation done already. What took us over a year is, at a second company, re-establishing four things. In September that was measured, eight working days.
| what you re-establish | why it differs per company |
|---|---|
| which administrations count | test administrations out, several entities side by side |
| norms per contract group | every company calculates glass, floors and regie differently |
| thresholds and escalation | who gets which question, from which amount upwards |
| ripeness limits | when this back office reports a period ready |
What stays is everything the year went into, the measurement core, the 131 flags, the card types, the gates, the night chain and the sector knowledge. That is exactly the layer you cannot buy and a software house does not just build.
One client sits in several administrations. Deduplicating on debtor code throws entities away. The key is code plus administration.
Two debtor numbers side by side, short for reporting and long for contract management, without a mapping table. Matching on name gets 97 of 271 exact. You need to know that before you start.
One export yields 108 fewer debtors in one file format than in the other. Same source, two formats, two truths.
Thirteen periods, not twelve. Every generic reporting tool that divides by 12 gives a systematically wrong answer.
The human decides. The system informs.
What you just read runs every night on real data. What is live has been measured, what is not finished we call roadmap and do not present as product. The open items sit in the same register as the working parts, and we are happy to show them.
Access to a source system, one domain expert who reviews the first questions, and one first priority that yields money or time.
The measurement core, 131 flags, 25 card types, four gates, the night chain and twenty-five years of sector knowledge as testable rules.
The receiving end is the weakest link and we know that from measurement. A question nobody picks up delivers nothing, however good the measurement.
All figures on this page were measured on 17-09-2026 on the running machines.