Reconciliation that cannot fix anything, on purpose

Any platform that bills through a payment provider eventually holds two versions of the truth: what it believes about a subscription, and what the provider says. They drift — webhooks are missed, a card fails between systems, someone changes something in the provider's dashboard.

The obvious product response is a reconciliation feature that detects the mismatch and repairs it. We deliberately built one that detects the mismatch and stops.

The problem with auto-repair

A reconciler that writes has to decide which side is right. That decision is made by code, at speed, on incomplete information, in exactly the situation where the information is known to be unreliable — that is what a mismatch means. Get it backwards and you have not fixed a discrepancy, you have overwritten the correct record with the wrong one and destroyed the evidence that they ever disagreed.

Money is also the category where a silent wrong answer is worst. A wrong device count is an annoyance. A wrong subscription state is a customer being charged for something they cancelled, or not charged for something they are using, discovered months later by someone reading a statement.

A reconciler that can write is a reconciler that can be confidently wrong in both directions at once.

What it does instead

• Validates the provider's response strictly before trusting any of it — a malformed or unexpected payload fails closed rather than being coerced into a clean-looking answer.
• Fails closed on duplicate identity: if a tenant maps to more than one provider customer, it refuses to guess which one is real rather than picking the newest and moving on.
• Classifies payment state truthfully, including the states nobody wants on a dashboard — past due, incomplete, and cancelled do not get rounded up to active.
• Restricts cross-tenant reconciliation reporting to root operators, because a report that spans tenants is a different trust boundary than a report about your own.
• Writes nothing. To either system. The regression suite asserts the absence of mutation, so "read-only" is a tested property rather than a design intention someone can quietly relax later.

Who fixes it, then

A human, holding both records, with the discrepancy and its evidence in front of them. That is slower, and it is correct. Automation is for the work where being right is mechanical. Deciding which of two disagreeing systems is telling the truth about someone's money is not that work.