AI Usage Billing Reconciliation Integrity Automation: The Function Every Reconciliation Called, That Never Existed

A background reconciliation step that fails loudly gets fixed quickly, because something visible breaks. A background reconciliation step that fails by returning an error the calling code already knows how to catch and log — and then simply continues — can fail silently for as long as nobody goes looking specifically for that log line, because from every user-facing vantage point, nothing appears wrong: messages still get answered, requests still complete. The absence is in a number nobody is staring at in real time: whether a specific database function, called constantly, actually exists.

The finding began with a single, specific line of code: the function responsible for recording a request's actual, final cost calls a named database function on every message with observed usage, and again on every refund of a reservation left orphaned by a request that died before finishing. Measuring the live database's own function catalog directly showed zero matches for that name — the function had never existed in production. Every call to it returned an error, which the calling service caught, logged as a generic failure, and moved past, silently, on every single occurrence since the code first shipped.

Two distinct consequences followed from that one missing function, both silent. First, because the reconciliation step that was supposed to replace an estimated cost with the real, observed cost never ran, the estimate and the real number were both left standing — summed together rather than reconciled — meaning a tenant's tracked spend grew faster than their actual usage justified, and a monthly cap could be reached before it honestly should have been. Second, because the same missing function was also responsible for returning reserved credit when a request died before completing, that credit simply stayed reserved and charged, permanently, for every request interrupted mid-flight — the exact mirror problem of the first.

Writing the fix required resolving a genuine complication: the repository's own earlier migration had been written assuming production's billing-scope tables had no organization column at all, when in fact production already had one, added independently at some point, with a stricter uniqueness guarantee than the assumption the repository was working from. Applying the older migration as written would have relaxed a real, currently-enforced guarantee in production purely to satisfy a description of a database that no longer existed. The fix was proven with a dedicated test harness that deliberately builds its starting point from production's OWN measured, current schema rather than the repository's assumption — the only one of several related harnesses built this way specifically because this was the one gap where the two genuinely diverged.

The actual fix that shipped adds several pieces together: the missing reconciliation function itself; a tenant-validation function and accompanying triggers, since the same investigation found it had been possible to write a row claiming one tenant while an organization-level filter silently pointed at a different tenant's data; a minimal ledger table that deliberately distinguishes a request that returned an observed FAILURE from a request that was simply INTERRUPTED with no observed end at all — collapsing those two into a single status would erase exactly the case where a reservation is left stuck with nobody aware it happened; and a function that converts an interrupted request into a resolved state and returns its reserved credit, without ever auto-refunding on its own — because deciding to reverse a charge automatically would be inventing an accounting decision that a person, with the actual number in hand, needs to make instead.

A request begins, reserves credit against the tenant's balance for its expected cost, and is interrupted before it finishes — a network hiccup, a restart, any ordinary cause. The code responsible for recognizing that interruption and returning the reserved credit calls the reconciliation function that does not exist; the call fails, is logged, and nothing more happens. The reservation stays charged, permanently, as if the request had completed successfully and consumed exactly that much. After the fix, the identical interruption is recognized, the reservation is explicitly released through the now-existing function, and the tenant's available balance reflects reality again — with the release itself recorded, not silent.

Every message's real cost now genuinely reconciles against its earlier estimate instead of adding to it, and every request interrupted mid-flight has its reserved credit returned through a function proven to exist and proven against production's own real schema — closing a gap where a single missing function had been silently failing on every call since it first shipped.

This automation governs the accuracy of cost tracking and reservation release for AI usage inside Synapse — it does not automatically refund or credit a tenant's account on its own; recognizing and releasing a stuck reservation is automatic, but any resulting balance adjustment remains a decision made by a person with the number in hand.

It is a reasonable default to trust that a repository's migration history accurately describes the database currently running in production — right up until the two have quietly diverged, at which point applying a fix written against the assumed state can do real, unintended harm to a guarantee the live database already enforces. Centriu's fix was built and proven specifically against production's own measured, current schema, not the version described in an older file, precisely because this was the one place in the investigation where the two genuinely disagreed.