Reconciliation & drift
Compare intent, provider, authoritative core, and ledger state; classify every mismatch; block unsafe dependent work; and repair through the owning domain rather than editing symptoms.
Reconciliation proves that what LendEasy intended, what an external provider reports, and what the authoritative financial record contains agree. It applies both to the native Lending Core and to bring-your-own-core bindings.
Match models
| Domain | Records compared |
|---|---|
| Payment | Payment intent ↔ provider settlement/return ↔ loan transaction ↔ journal entry. |
| Funding | Funding request ↔ payout provider ↔ disbursement transaction ↔ journal entry. |
| Core action | Frozen request ↔ core acknowledgement ↔ resulting facts. |
| Merchant remittance | Sales report ↔ calculated remittance ↔ settlement ↔ purchased-balance reduction. |
| Statement | Generation key ↔ fact snapshot ↔ artifact hash ↔ delivery. |
| Identity mapping | LendEasy ID ↔ current external-core ID and lifecycle. |
Lifecycle
Example: settled without ledger post
{
"exceptionId": 3301,
"exceptionType": "SETTLED_NOT_POSTED",
"targetType": "PAYMENT_INTENT",
"targetRef": "9011",
"status": "open",
"detail": {
"providerRef": "ach-settle-88"
},
"createdAt": "2026-09-15T14:30:00Z",
"lastSeenAt": "2026-09-15T18:30:00Z"
}The safe remedy is not to debit Maya again. The provider already settled. The payment domain verifies the event, posts or recovers the missing ledger effect idempotently, and reruns the match.
Difference classes
- expected but still within normal pending window;
- timed out with unknown external outcome;
- provider settled but authoritative posting absent;
- authoritative state changed without a governed request;
- acknowledgement says complete but facts did not change;
- applied payload or amount differs from requested hash;
- duplicate provider/source reference;
- return or reversal missing on one side;
- identity mapping missing or points to an inactive resource;
- stale fact feed beyond execution threshold.
Unknown outcome is not failure. It parks dependent work and uses status/read or reconciliation—not blind resubmission.
On the built-in core these surface as the typed exception catalog: STUCK_BEFORE_SUBMIT, SETTLED_NOT_POSTED, RECORDED_NOT_POSTED, RETURN_NEEDS_REVIEW, DUPLICATE_REFERENCE, TXN_NO_RECORD, and EVENT_NO_RECORD.
Operational effect
Severity and domain determine which work is blocked. A payment mismatch may suppress duplicate collection, receipts, closure, and downstream fees while allowing read-only investigation. A stale bankruptcy restriction feed blocks contact much more aggressively than a stale non-critical profile field.
Resolve with evidence
POST /v1/recon-exceptions/{exceptionId}/status moves an exception between open, in_review, resolved, and exported—a note is required to resolve—and it does not perform the financial repair. Resolution cites the payment, funding, governed command, identity-map correction, or other authoritative result that fixed the difference. GET /v1/recon-exceptions/export downloads open exceptions as a CSV for external working sessions and marks them exported.
Measures
Track count and amount by type, age percentiles, critical time to acknowledge/repair, recurring source, false positives, reopened items, and percentage auto-matched. A declining exception count is meaningful only if detection coverage and freshness remain stable.