Source of Record (SoR), write-off, charge-off, and post write-off debt management

Source of Record: balance truth, write-off, GL, recoveries, and DCA

Key illustrations

Definitions (quick reference)

1. Why this matters

Many issues in recoveries, DCA management, reconciliation, and customer complaints trace back to one gap: no one is clear where the truth of the balance sits after write-off.

People often assume one of the following is enough on its own:

• The core banking system still holds the full operational balance.
• The general ledger holds enough detail to run collections.
• The DCA platform can be treated as the balance of record.

In practice, none of those assumptions is sufficient by itself. You need a clear view of which system answers which question, and how they reconcile.

2. What we mean by Source of Record

SoR is a control concept, not a vendor product name. It means: if you need the balance, status, or history of this debt, which system do you trust for that purpose?

Pre write-off, the core banking (or loan) system is usually the operational SoR for the live loan: it holds the balance, processes payments, and drives much of operational reporting.

Post write-off, the picture gets more complicated. The loan may be closed or frozen in core while recoveries still needs an account-level view for placement, contact, and regulatory questions. That is why a credit provider (CP) owned recoveries or collections book is usually in play (see below).

3. What actually happens at write-off

The simple view (often wrong)

Default → write-off → debt is gone.

The real view

The bank concludes the loan is unlikely to be recovered for accounting purposes, takes an accounting loss, and the obligation can still exist for collections and customer treatment. Collections activity often continues.

Write-off is first an accounting outcome. What happens next depends on law, policy, and product.

4. Charge-off vs write-off

Textbook: charge-off is a classification or trigger; write-off is the accounting entry that removes or reduces the asset and recognises loss.

In practice, many banks combine charge-off and write-off on the same timeline and use the terms interchangeably in conversation because systems align policy triggers and finance posting, and operations do not split the two.

Typical flow: threshold (for example 180 DPD unsecured, or a secured recovery trigger) → non-performing classification → finance posts debit to loss, credit to loan asset (simplified). Teams may say it was written off and charged off in one step.

Why the distinction still matters: charge-off drives stage, reporting, and routing; write-off is the balance sheet consequence. Neither term, by itself, means the debt is gone for all purposes. Forgiveness, sale, statute, or settlement are separate ideas.

Regional language (orientation only): many US materials foreground charge-off and DPD thresholds. Australia and New Zealand packs often use write-off and impairment language in finance papers. Fix definitions in your policy and chart of accounts. This page is not accounting or legal advice.

5. What happens to the account after write-off

Core behaviour (common): after write-off, many cores close or retire the loan, freeze the balance for normal transaction processing, or stop treating the account as actively accruing the same way. The loan asset is no longer active in the originating sense.

Recoveries perspective: the customer may still owe; payments may still occur; collections must continue.

The gap: the system that held the performing loan is often not the right place to run post write-off work at scale. Banks use recoveries books, subledgers, or case platforms under CP control.

6. Role of the General Ledger (GL)

The GL tracks totals for write-offs, recoveries, impairment movements, portfolio and period P&L, and often a recoveries line that aggregates recovered cash.

The GL does not replace account-level servicing for “what does this customer owe right now?” in operational terms.

Example: customer owed $10,000 and pays $2,000. The GL records $2,000 recovery in the period (simplified). GL alone does not replace a per-customer remaining balance view: that lives in CP-controlled operational systems.

7. The shift in Source of Record (two questions, not two owners)

After write-off, separate questions:

1. Financial truth (GL and finance subledgers): totals, impairment, period recovery, P&L.
2. Operational truth (recoveries under CP): account-level balance, payments, stage, holds, placement, recall, customer activity.

Critical principle: the credit provider remains accountable for reporting and conduct. The operational place you query for recoveries is typically a CP-owned recoveries or collections system of record, not the DCA platform.

8. Why a recoveries-capable system must hold operational truth

Someone must answer per account: what does the customer owe now, what have they paid, what remains, what stage or placement applies? The GL cannot answer at customer level. The original core may be frozen or closed for that product. The bank implements operational SoR in a recoveries stack it controls.

Example: written off at $10,000; customer pays $2,000 via DCA. The recoveries (CP) view should show payments $2,000 and remaining $8,000 (subject to fees, post-WO interest rules, policy). At the same time, GL shows $2,000 recovery in the period for finance. Both can be correct. They answer different questions.

9. Interaction with the DCA model

Flow (simplified): accounting write-off → operational balance and placement in CP recoveries → send to DCA (R1) per policy → DCA collects and reports → CP updates authoritative balance and posts to finance per rules.

Critical control: the credit provider remains the Source of Record for balance and outcomes that drive conduct and regulatory position. The DCA provides reported activity and balances for reconciliation, not silent override of CP truth. Dual-state design: CP / DCA files.

10. Why reconciliation becomes critical

You have DCA-reported balance and status, CP recoveries authoritative view, and GL or finance aggregates. If these drift, customers can be over-contacted or worked on stale amounts; payments can lag; audit trails weaken.

Typical cadence: daily payments, status, recall, balance alignment; weekly trends in breaks and delays; monthly full alignment for governance and attestation.

Control checks (examples)

11. Common failure patterns

1. No clear SoR post write-off (spreadsheets, partial exports) → inconsistent balances and disputes.
2. GL treated as account truth for contact decisions → no stable per-customer view.
3. DCA becomes de facto SoR → conduct and governance risk.
4. Weak reconciliation → errors compound.

12. End of lifecycle

Terminal states depend on your policy and law: paid or settled, debt sold, abandoned, forgiven.

Abandon versus forgiveness

Many programmes use both as terminal paths: no further internal work, no DCA placement, no legal escalation under that policy. The customer-facing outcome can look similar (for example both move to closed or inactive treatment). The usual difference is why you stopped, usually captured in the reason code, not only the label shown to the customer.

Typical listing may be settled or not paid in full where applicable. Legal and compliance own wording.

Recommended data: store End_State_Type (Abandon, Forgive, and so on) and End_State_Reason (coded) so commercial exits are reportable separately from conduct-driven exits.

Waiver

Waiver may mean stop pursuing or waive part of the balance under delegated authority. Legal meaning varies: your legal team defines whether waiver extinguishes debt or only ends collection activity.

Crystallise (secured)

Crystallised shortfall usually means the unsecured residual is fixed after asset realisation. That amount then flows into unsecured recoveries, DCA, sale, or waive or abandon. It is a quantification step, not the same label as forgiveness or abandon.

13. Bringing it together

CP is accountable for coherent design across core, recoveries, GL mapping, and DCA feeds.

14. Final takeaway

Write-off removes or reclassifies the loan asset for accounting. It does not, by itself, end all operational or legal meaning of the debt. If you do not define where the operational balance lives after write-off, placement, recall, customer treatment, and reporting break.

Bottom line

• Clear SoR ownership (CP-led operational system, not the DCA).
• Clean separation of GL totals vs account-level recoveries truth.
• Strong reconciliation between CP, DCA-reported state, and finance.
• Governance over DCA data as inputs, not silent authority.

This is the foundation for recoveries, DCA management, and oversight.

Questions to resolve before sign-off

1. Where is the account-level balance stored and updated after write-off?
2. Who owns payment posting from internal channels and from DCA feeds?
3. How often do you reconcile CP recoveries to GL recovery lines, and who owns breaks?
4. Can you explain a customer balance at any time from CP systems, not the DCA portal alone?
5. Are end states coded with reason so commercial and conduct exits report separately?

Layer 3 reporting and Source of Record

Monthly governance reporting should be built from CP-controlled balances and cohort definitions, with DCA-reported fields used for challenge and dual-state checks. If Layer 3 is assembled only from vendor PDFs, you lose the link between operational SoR and finance truth, and recovery rates become arguments instead of measurements. See Reporting and Reporting data lineage.

Related topics

• CP / DCA files and SoT (feeds, dual-state, reconciliation)
• Written-off allocation (MoSCoW, R1, R2 journey)
• Recoveries decision (master treatment paths)
• Glossary (SoT, SoR, R1, R2)

Back to pack home