Chargeback Traceability Automation: Correcting a Mistake Looked Just Like Making One

The entire value of a financial ledger as an audit trail comes from being able to answer, precisely, why any given entry exists — and a correction entry's own reason for existing is inseparable from the specific mistake it corrects. Recording a correction using the same generic record type as any other unrelated adjustment, with no structural link back to the entry being corrected, throws away exactly the information that makes the correction meaningful as a correction: a reviewer is left with two entries that happen to roughly offset each other, with no way to confirm that relationship was ever real, or that it only happened once.

A single, general-purpose "manual adjustment" record type is the simplest way to give staff a way to correct a balance for any reason at all, and it genuinely is sufficient for the many legitimate cases where an adjustment has nothing to do with reversing a specific prior entry — a goodwill credit, a promotional bonus, a rounding correction. The gap opens specifically for the narrower, more consequential case of correcting a KNOWN, SPECIFIC mistake: that case has real structural properties a generic adjustment does not capture on its own — which exact entry is being corrected, whether the correction's own size and direction genuinely match that entry, and whether that same entry has already been corrected once before. Building those structural guarantees requires a distinct record type built specifically for that narrower case, rather than relying on a general-purpose one to imply a relationship it was never designed to represent.

Centriu Loop's own cashback ledger previously had only its general-purpose manual-adjustment record type available for correcting a wrongful credit — the identical record type used for any other unrelated balance change, with no structural connection back to a specific prior entry.

The fix introduces a dedicated chargeback movement type, structurally separate from an ordinary adjustment from the moment it is created. Every chargeback record MUST reference, through an explicit foreign key, the exact original ledger entry it is reversing — the relationship between a correction and the mistake it corrects is now a structural fact enforced by the database itself, not something inferred later from context or a free-text note. A dedicated database constraint further guarantees that a single original entry can be linked to, at most, one chargeback, ever — attempting to record a second chargeback against an already-reversed entry is rejected outright by the database's own uniqueness guarantee, making an accidental or deliberate double-reversal of the same mistake structurally impossible rather than merely a practice staff are trained to avoid. A companion check confirms a chargeback's own recorded amount is genuinely the mathematical inverse of the entry it targets, keeping the correction and the mistake it corrects consistent by construction rather than by convention.

The ledger's own general-purpose manual-adjustment type remains available, unchanged, for every legitimate case that genuinely has nothing to do with reversing a specific prior entry — the fix narrows what a correction looks like without removing the flexibility a true adjustment still needs.

Before the fix, correcting a wrongful $50 credit produced a second, generic adjustment entry for -$50 — indistinguishable, from the ledger's own structure alone, from any other unrelated $50 debit a staff member might record for a completely different reason, and with nothing stopping that same original credit from being "corrected" a second time by mistake. After the fix, the identical correction is recorded as a chargeback that explicitly references the original credit entry by its own identifier, with the database itself refusing outright if anyone attempts to record a second chargeback against that same entry.

Centriu Loop's cashback ledger now records a correction to a known, prior mistake as a dedicated chargeback type, explicitly linked to the exact entry it reverses and guaranteed by a database constraint to happen at most once per entry — closing a gap where a correction and an unrelated adjustment looked identical in the books, with nothing preventing the same mistake from being reversed more than once.

This automation covers specifically how Centriu Loop's ledger distinguishes a correction to a known prior entry from an ordinary, unrelated manual adjustment. It is a distinct mechanism from this pillar's separate pages on the ledger's own append-only write protection and its FIFO expiration model — both build on the same underlying ledger but address genuinely different questions, covered on their own pages.

A single, general-purpose adjustment type is simpler to build and is genuinely sufficient for the many legitimate corrections that have nothing to do with reversing a specific known mistake. It stops being sufficient the moment a correction's own value depends on being provably, structurally tied to the exact entry it reverses, and on being guaranteed to happen at most once — properties a general-purpose type was never designed to enforce. A dedicated record type, tied to its target by an explicit foreign key and protected by a uniqueness constraint, is the only version of the two that makes a correction's own relationship to the mistake it corrects a database-enforced fact rather than a matter of trusting whoever recorded it.