UNKNOWN Is Not a Mismatch: Reconciliation Exception Taxonomy

Four evidence outcomes, one assertion at a time

For this method, the unit of classification is not “the payment forever.” It is a versioned assertion inside a case.

Companion artifact: Download the full Exception Taxonomy (.txt).

This creates a crucial separation:

reconciliation result ≠ cause ≠ payment/rail status ≠ human disposition.

A known break can have an unknown cause. A provider can report a payment status that does not answer a finance assertion. A reviewer can accept an unresolved exception administratively without converting the underlying evidence state to MATCH.

Why scope beats a red/green case color

One business operation can contain several simultaneous assertions:

• does the expected amount equal the recorded amount?
• is the asset/currency/network/contract identity the same?
• does the on-chain transaction meet the selected finality criterion?
• did the local payout reach the beneficiary-side evidence source?
• did the bank leg become available funds by the stated cutoff?
• is the internal ownership or client allocation authoritative and complete?

A single headline color hides this structure.

Suppose a synthetic case shows an Ethereum-side amount of 250.00 matching the expected amount, while the reviewer cannot access the bank evidence needed to establish the fiat credit. The chain amount assertion can be MATCH while the fiat-credit assertion remains UNKNOWN. Calling the entire case “settled” would overstate the evidence. Calling it merely “mismatched” would also be wrong.

Ethereum’s current JSON-RPC documentation illustrates why even “on-chain” needs a defined criterion: latest, safe, and finalized are distinct block tags. A reviewer should preserve the source-specific state actually used rather than inventing a universal confirmation count.

Absence needs a coverage argument

MISSING is a stronger claim than “I did not see it.”

Before classifying a required record as MISSING, record the search boundary:

• correct tenant/account/entity;
• correct period and timezone/cutoff;
• correct filter and identifier;
• pagination or equivalent population coverage;
• expected-arrival horizon or late-arrival rule;
• source access actually working;
• an independent reason the record should exist now.

If the source returns a 403, times out, or only exposes an incomplete result set, the reviewer has an evidence-access problem. For an assertion that depends on that source, the safer result is UNKNOWN.

This is also why expected time and escalation time should be separate. A future payout stage is not “missing settlement” merely because it has not happened yet. not_applicable or pending can sit on another axis until the stage becomes due. Once a record is required at the cutoff, it can be MISSING even before an internal escalation SLA expires.

The NULL trap: a query result is not a finance conclusion

PostgreSQL documents two useful but easily confused semantics. Ordinary comparisons involving NULL yield null/unknown. Null-safe predicates such as IS NOT DISTINCT FROM can treat two nulls as technically equal.

That can be correct SQL and still be the wrong financial conclusion.

If two required amount fields are both null because neither source supplied the value, “null-safe equal” does not establish that the financial amounts match. The reviewer first needs the schema meaning of null for that exact field. Is null a valid business value? Does it mean not applicable? Is it a missing mandatory input? Is it a redaction? Is the source unreadable or inaccessible?

Known zero is different. 0 can be a real comparable value. Do not coerce null, empty string, missing row, access denied and known zero into the same representation.

Event delivery is not economic movement

Payment operations also fail when event records are confused with money movements.

Stripe’s current webhook documentation says event delivery order is not guaranteed and the same event may be delivered more than once. It recommends using event IDs—and, for some separate Event objects, the underlying object ID plus event type—to handle duplicates.

The reviewer implication is narrow: duplicate notification does not prove duplicate payment. Preserve event identity, provider object identity, payment/transfer identity and the economic mapping separately.

The inverse matters too. Two separate transfers can have the same amount. Deduplicating solely because 100.00 appears twice can erase a real second economic event.

The same discipline applies to late messages. A late-arriving old event should not automatically overwrite newer authoritative evidence merely because it arrived last. Keep event_time, source_updated_at, received_at, retrieved_at, comparison cutoff and evidence version as separate fields when they matter.

Payment status and failure reason are separate from reconciliation class

Provider-native status belongs in its own field.

Circle’s current CPN documentation, for example, distinguishes payment-level failure reasons such as ONCHAIN_SETTLEMENT_FAILED and FIAT_SETTLEMENT_FAILED from on-chain transaction failure reasons such as INSUFFICIENT_GAS_BALANCE, TX_ALREADY_CONFIRMED and FAILED_ONCHAIN.

Those reason codes are useful provider evidence. They are not replacements for MATCH / MISMATCH / MISSING / UNKNOWN.

A provider can say a payment failed while a separate assertion—“does our internal case record reproduce the provider’s terminal state?”—is a MATCH. Conversely, a provider can show a completed state while the reviewer still has UNKNOWN ownership allocation or UNKNOWN bank availability because those are different assertions and different authorities.

Do not turn this method into instructions to retry, replace, fund, post or release a live payment. The operational next action here is evidence collection and human review.

Gross/net mapping comes before residual classification

A 100 gross amount and a 98 net receipt do not automatically prove a 2-unit error.

First establish the mapping rule:

gross amount − documented applicable fee(s) = expected net amount

If a synthetic rule explicitly documents a 2.00 fee, then a 98.00 net receipt can MATCH the expected net assertion.

If the fee is not documented, the reviewer must not manufacture it to make the case close. If 100 and 98 are genuinely comparable values for the same assertion, the known delta is a MISMATCH while cause_status=unknown. If the intended expected-net value itself cannot be established, that different assertion may be UNKNOWN.

For batches and splits, totals are not enough. One-to-many and many-to-one mappings can hide line-level breaks. Two synthetic line errors of +5 and −5 can produce a perfectly matching batch total of zero delta. The total assertion may MATCH while both line assertions are MISMATCH.

The Exception Evidence Card

A useful review object should force the distinction between result, evidence, cause, workflow state and decision.

The core card keeps fifteen fields:

1. case/transaction ID;
2. classification: MATCH / MISMATCH / MISSING / UNKNOWN;
3. expected state;
4. observed state;
5. source(s) checked;
6. source timestamp/freshness;
7. evidence still required;
8. authoritative-source question;
9. owner;
10. exception age/SLA;
11. next action;
12. escalation trigger;
13. human disposition;
14. closure evidence;
15. reopen condition.

Companion artifacts: Download the blank Exception Evidence Card (.txt) · Download worked synthetic examples (.txt).

For multi-assertion cases, add an extension block with assertion_id, applicability, scope/cutoff, rule/version, raw and normalized values, source lineage/coverage, provider or rail state, cause confidence, severity, chronology, superseding evidence IDs and review state.

Do not let the extension silently replace the original fields. The point is traceability.

A worked synthetic timeline: UNKNOWN → MISSING → MISMATCH → MATCH

All IDs, amounts and times below are invented.

At 09:00 UTC, a synthetic reviewer cannot access the bank evidence endpoint for SYN-TIMELINE-001. The fiat-credit assertion is UNKNOWN. The timeout says nothing about whether the credit exists.

At 09:30, the reviewer retrieves the complete synthetic statement window for the correct account and period. The required expected record is absent inside that declared boundary. The assertion becomes MISSING.

At 11:00, a late bank record appears for 95.00 against an expected 100.00 in the same synthetic currency, unit and cutoff. The assertion becomes MISMATCH. The cause remains unknown.

At 13:00, a superseding corrected source record shows 100.00. A new comparison run produces MATCH. The earlier UNKNOWN, MISSING and MISMATCH states stay in the evidence history; they are not rewritten out of existence.

This sequence is illustrative, not a required lifecycle. Some cases never become MISSING. Some stay UNKNOWN. Some MISMATCH cases close with unresolved cause. Some MATCH states later reopen when a reversal, reorg, corrected mapping or new bank statement changes the evidence.

Closure is a decision boundary, not a synonym for MATCH

A case can be administratively closed with explicit unresolved limits.

For example, a designated human might decide that an UNKNOWN ownership field does not block a separate bounded operational task. The disposition can be accepted_exception or closed_with_explicit_unresolved_limit if the organisation’s rules allow it. The underlying classification remains UNKNOWN.

Likewise, correcting a source record does not erase the old mismatch. It creates new evidence and requires a new comparison run.

Every closure should answer:

• what exactly is being closed?
• what evidence supports closure?
• who has authority to make the disposition?
• what remains unresolved?
• what event would reopen the case?

How to test whether this taxonomy is actually useful

The taxonomy should not be justified by its own neatness.

A real validation should compare a baseline process with the proposed framework on comparable cases. Predefine measures such as reviewer clarity, false closure, time spent in UNKNOWN, rework, disagreement rate and evidence-completeness defects. Use adjudicated reference outcomes where they exist; state plainly when ground truth is unavailable.

A negative result is valid. If the existing workflow already distinguishes these states reliably, the extra structure may add cost without enough benefit.

Synthetic self-consistency is not evidence of productivity, SLA improvement, financial savings, customer demand or model accuracy. The synthetic examples and internal checks used during preparation only demonstrate that the published decision table behaves consistently on invented fixtures.

Limits and source boundary

This is a reviewer-oriented framework, not a standard, certification, accounting policy, regulatory interpretation or shipped Treasury Desk reconciliation engine.

The Tessermark social post is the research hypothesis, not independent proof that the taxonomy improves operations. PostgreSQL documents SQL semantics, not finance controls. Stripe, Circle and Ethereum documentation describe their own interfaces and states; those examples must not be universalized to every provider, chain or banking rail.

The strongest safe conclusion is therefore conditional:

Preserving MATCH, MISMATCH, MISSING and UNKNOWN at the assertion level—while keeping cause, provider/payment state, human disposition and closure evidence separate—creates a reproducible reviewer language. Whether it improves a real reconciliation process remains an empirical question.

Sources

• Tessermark, captured LinkedIn research post in Treasury Desk source corpus, retrieved 2026-10-04. The raw capture contains damaged punctuation and no safely recovered exact post permalink, so this article paraphrases rather than quotes it verbatim.
• PostgreSQL, “Comparison Functions and Operators”: https://www.postgresql.org/docs/current/functions-comparison.html
• Stripe, “Receive Stripe events in your webhook endpoint”: https://docs.stripe.com/webhooks
• Circle CPN, “Payment and transaction failure reasons”: https://developers.circle.com/cpn/references/errors/payment-and-transaction-failure-reasons
• Ethereum.org, “JSON-RPC API”: https://ethereum.org/developers/docs/apis/json-rpc/
• Treasury Desk, “FX Meets Stablecoins: The Exception Chain Between Quote and Close”: https://treasurydesk.io/fx-stablecoins-exception-chain-quote-to-close/
• Treasury Desk, “The Exception Queue Is a Training Set for Automation – But Only After Adjudication”: https://treasurydesk.io/the-exception-queue-is-a-training-set-for-automation-after-adjudication/
• Treasury Desk, “Agent-Readable APIs Need Reviewer-Readable Recovery Paths”: https://treasurydesk.io/agent-readable-apis-reviewer-readable-recovery-paths/
• Treasury Desk, “One Customer Experience, Five Rails: Build an Authoritative Payment Case”: https://treasurydesk.io/one-customer-experience-five-rails-authoritative-payment-case/

Reader action: take one public or synthetic reconciliation case, split it into explicit assertions, and try to classify each assertion without guessing across missing evidence. If the framework adds no clarity, that is useful validation too.