The approach
Software fails loudly or lies quietly.
A billing pipeline can pass every schema check, return success on every call, reconcile cleanly, and still produce the wrong amount. The failure is called revenue leakage, and industry estimates put it at one to five percent of revenue, highest where pricing is usage-based and terms change mid-cycle. It is invisible by construction: a crash pages someone, a plausible and wrong number gets paid.
We have one worked example in public. A catalog price change that did not reach the invoice, where the preview and the final bill agreed with each other and both were wrong. The reproduction, with its limits stated.
Available now: the billing integrity audit
A fixed-fee, fixed-scope engagement. We take one revenue path on a pinned revision of your billing code, find where it reports success and should not, and deliver each finding with the input that reproduces it, a regression test that fails on the current code and passes on the fix, and a written list of what we did not examine.
The first offered scope is one catalog price-change scenario at a proposed fixed fee. A result of no mismatch is reported as exactly that, not dressed up as a catch.
In design: the self-contradiction scanner
Independently recomputing your correct invoice would require your business arithmetic, encoded by hand, per customer. We think the honest product avoids that entirely: it reads your historical billing events and finds where your system contradicts itself.
- Two code paths that read the same field but disagree about what it means.
- A value your ingest accepts that your aggregation silently excludes.
- Two defaults for one missing value, so an item is billed under one assumption and reported under another.
A contradiction is checkable without knowing what any invoice should have said. The scanner's output is contradiction counts and the transaction identifiers behind them, never an invented dollar figure. You price the damage from your own ledger; we assert only the defect we can reproduce.
Planned: mutation checks in your CI
The continuous version runs where your engineers already live. On each change, it replays historical payloads with small deterministic mutations and holds the result to properties that need no knowledge of your business rules:
- The same facts arriving in a different order must produce the same final state.
- The same event delivered twice must never bill twice.
- Two spellings of the same value must aggregate as the same value.
- Anything accepted at ingest must be visible to the computation that bills it, or be rejected loudly.
Every defect the audits find becomes a planted case in this corpus, and the corpus publishes its catch rate against planted defects before it says anything about a clean run. A test suite that has never demonstrated detection proves nothing by silence.
Every run signs a receipt that states its own limits
Scanner and CI runs emit a signed record: what corpus version ran, how many variants executed, the catch rate on planted defects, what was found, and what was not covered. That is evidence you can hand to an auditor or an acquirer: proof that a control ran, with its boundaries printed on it.
What we will never sell is a stamp. Ten million clean variants prove that ten million variants ran and found nothing. They do not prove the absence of defects, because absence of observed behavior in one run is not proof that the behavior is absent. A signature shows who signed a record; it cannot turn a wrong number into a right one. Any vendor offering certified correctness is selling the exact failure this field exists to catch.
Where this stands
The audit is available now and nobody has bought one yet; this page will say so until that changes. The scanner and the CI checks are design-stage and run nowhere. Each layer gets built only after the one before it has paid for it and shaped it. The method behind all three is public: our reproductions, fixes, and reviews are merged in public billing and security repositories, and every public claim we make ships with the input that reproduces it.
Talk to us
If you own billing arithmetic and want one path checked before the next release, start with the study. If you just want to compare notes on how you verify invoice amounts today, that conversation is welcome and free.
See the study →