Aging Accounts: Managing Limitation Periods From the Creditor Side | HL Hunt

Aging Accounts: Managing Limitation Periods From the Creditor Side | HL Hunt
Payments & AI

Aging Accounts: Managing Limitation Periods From the Creditor Side

Ask most collections operations which of their accounts are past the applicable limitation period and the honest answer is that nobody knows. The date is rarely recorded, the applicable law is rarely established, and the status is left to whoever happens to notice — which produces an exposure in both directions. Accounts get pursued in ways that may not be appropriate for their status, and accounts that could be pursued get abandoned because nobody checked. This is a data problem with legal consequences, and the data part is the part an operation can actually fix.

By the HL Hunt Research Desk · 15 min read · Updated August 2026

Why this is a data problem

The law is complicated and varies; the operational failure is simpler and entirely self-inflicted.

FailureConsequence
Date never recordedStatus can't be computed for any account
Applicable law never establishedNo period to apply even with a date
Relevant events not loggedThe calculation is wrong
Status left to judgmentA collector decides a legal question on a call
No defined treatment pathOut-of-statute accounts work through the standard sequence

Every row is fixable with fields and rules, which is the useful observation: the legal complexity is real and it doesn't prevent an operation from knowing what it's holding.

And the fourth row is the one that matters most in practice. A collector on a call cannot work out a limitation question — it depends on a date, a jurisdiction, an obligation type, and possibly events years ago. Leaving it to them guarantees inconsistency, which per our monitoring analysis is the condition under which conduct problems become systematic rather than occasional.

Establishing the date

Harder than it sounds, and the reason most operations don't have it.

What the period runs from is defined by law, varies by obligation type and jurisdiction, and refers to an event frequently years in the past.

Why it's hard to reconstruct:

  • The account has passed through systems, each retaining different fields.
  • The balance history may not identify the relevant event clearly.
  • Restructures and arrangements complicate it, potentially materially.
  • Acquired portfolios frequently arrive without it, per our debt sale analysis.
  • Migrations lose fields, per our records analysisand this is the field most likely to be dropped, because nobody uses it operationally until they need it.

The response is the same as everywhere else in this library: capture it as a structured field at the time. An operation recording it today will know the status of everything it originates; one hoping to derive it later mostly won't.

And for accounts where it genuinely can't be established, that's a status too — record it as unknown rather than leaving it blank, so the accounts needing a conservative treatment are identifiable.

Unknown is a status
Accounts where the date can't be established need their own treatment path. A blank field and an established date look identical to every system reading it.

Which law applies

The question that has to be answered before any period can be applied, and it isn't always obvious.

Which jurisdiction's law governs depends on factors that vary — where the consumer is, where the agreement was made, what the agreement says, and the nature of the obligation. Periods themselves differ substantially between states and by obligation type.

What this means operationally:

  • It's a question for counsel, resolved as policy rather than per account.
  • The answer may differ across your portfolio, so one rule may not fit everything.
  • Consumers move, which can matter.
  • Agreement terms may address it, and those terms need to be known.
  • The law changes, so a policy set years ago needs periodic review.

What an operation should do: get counsel to define the rule, encode it, and review it annually. The point is to move the question from the call to the system, where it's answered consistently and can be checked.

This report deliberately gives no periods or jurisdictional detail. They vary enough that any general figure would be misleading, and the operational message doesn't depend on them.

Events during the account's life

Where the calculation gets genuinely complicated and where operations create exposure without intending to.

In some jurisdictions a payment or an acknowledgment can affect the period; in others it can't, and the specifics vary considerably.

Why this is an operational matter rather than only a legal one:

  • A small payment obtained during a collection contact can change an account's legal position — potentially without anyone involved intending or realizing it.
  • An arrangement may involve an acknowledgment that has an effect.
  • A collector encouraging a token payment on an old account may be doing something with consequences nobody briefed them on.
  • Per our consumer-side guide, the consumer is frequently unaware of this too — which makes it a fairness question as well as a compliance one.

What an operation needs:

  1. Log every payment and arrangement with dates — which you do anyway, but the field has to be usable for this.
  2. Log acknowledgments where relevant, which most systems don't capture.
  3. Defined guidance for collectors on accounts near or past a date.
  4. Counsel's view on what your treatment should be, documented.

Item three is where the risk actually sits. A collector whose incentive is to obtain a payment, working an old account with no guidance, will do the thing that gets a payment — and per our incentive analysis, that's a predictable consequence of the compensation structure rather than a training failure.

The token payment on an old account

"Just send twenty dollars to show good faith" is a standard collection move and, on an account near a limitation date, it may do something significant. Operations working aged accounts need explicit guidance on this, because the collector has no way to know and the incentive points one way.

Making status a field

The operational fix, and it's the same architecture pattern as every other propagation problem in this library.

Limitation status should be a computed field on the account that every system reads before acting — not a note, not a judgment, not something a supervisor checks.

What it takes:

  1. The date field, populated or explicitly unknown.
  2. The applicable jurisdiction, per counsel's rule.
  3. The obligation type, since periods differ.
  4. Relevant events, logged with dates.
  5. A computed status — comfortably within, approaching, passed, or unknown.
  6. Routing rules keyed to that status.
  7. Recomputation when anything relevant changes.

The four-state status in item five is more useful than a binary, because "approaching" and "unknown" both need handling and neither is captured by in-or-out.

And per our restrictions analysis, the propagation requirement is identical: the status has to reach the dialer, the letter generation, the digital channels, and any agency — because a status that only the case management system knows about doesn't change what the campaign does.

Treatment once it has passed

What changes, and this is squarely a question for counsel.

Voluntary payment is generally still possible and conduct requirements apply, differing by jurisdiction — some require specific disclosures, some restrict particular representations, and litigation on such an account raises serious issues.

What an operation needs in place:

  • A defined treatment path that counsel has approved, distinct from the standard sequence.
  • Any required disclosures built into the communications for that path, not left to a collector to remember.
  • Clear rules on what may and may not be said.
  • An absolute bar on legal action on accounts in this state, enforced by the system rather than by policy.
  • Guidance on payments, per the section above.
  • Exclusion from sale, or clear disclosure of status if sold — per our debt sale analysis, selling accounts whose status you haven't established passes a problem on rather than resolving it, and representations about a portfolio are a matter you remain exposed on.
  • Monitoring for any activity inconsistent with the path.

The fourth deserves a system-level control rather than a procedural one. Litigation on an out-of-statute account is among the more serious failures available in this area, and a policy that says not to do it is weaker than a system that won't let you.

The commercial question is separate and worth asking honestly. Per our cost analysis, accounts in this state are frequently uneconomic to work anyway — so for many operations the right answer is a defined write-off rather than a treatment path, and that's a cheaper decision than building the compliant version.

Portfolios you acquired

Where the data problem is worst and the exposure arrives ready-made.

Per our debt sale analysis, acquired accounts frequently come with incomplete records — and the limitation-relevant date is among the fields most likely to be missing or unreliable.

What to do at acquisition:

  1. Require the date as part of the file, specified in the purchase agreement.
  2. Require the payment and acknowledgment history, not just a balance.
  3. Sample and verify rather than accepting the data as given.
  4. Establish what representations were made about the portfolio's status.
  5. Treat unverifiable accounts conservatively until established.
  6. Price for it — a portfolio without reliable dates is worth less, and that should be in the negotiation rather than discovered afterwards.

Item six is the one that changes behaviour. Data quality on these fields affects what the portfolio can lawfully be worked for, which makes it a valuation input rather than an operational inconvenience — and buyers who price it get better data because sellers respond to what's priced.

Accounts approaching a date

The other side, and it's a recovery question rather than a compliance one.

An operation that intends to pursue an account formally has a deadline nobody is reminding it of. Which produces the mirror failure: accounts that could have been pursued, weren't, because the date passed while they sat in a queue.

What to run:

  • A standing report of accounts approaching a date, with enough lead time to act.
  • A decision point at a defined interval before — pursue, settle, or write off.
  • Escalation for larger balances, where the decision warrants attention.
  • Settlement authority, per our settlement analysisa negotiated resolution before the date frequently beats both alternatives.
  • A defined write-off for what doesn't justify action.

The fourth is the commercially sensible answer for most accounts and it needs the report to happen at all. An account worth settling at a discount three months before a date is worth nothing three months after, and the difference is entirely a matter of whether anyone looked.

This is the same structure as the claim deadlines in our deceased accounts guide and the lien deadlines in our commercial guide: a date that runs silently and forecloses an option, where the only defence is a report.

Status as a field, not a judgment

HL Hunt AI Debt Collection holds limitation-relevant dates and events as structured fields, computes account status against configured rules, routes by that status across every channel, and reports on accounts approaching a date.

Explore HL Hunt AI Debt Collection

Frequently asked questions

What does a limitation period do to a debt?

It generally limits the period for pursuing a claim through the courts rather than extinguishing the obligation, though the effect varies enough by jurisdiction that specific advice is necessary.

Why is the start date hard to establish?

It's defined by law, varies by obligation type, and refers to an event years in the past that systems, migrations, and portfolio sales frequently fail to preserve.

Can a payment restart a limitation period?

In some jurisdictions, with specifics varying. Operationally it means a token payment obtained on a call can change an account's legal position unintentionally.

Can an out-of-statute account still be collected?

Voluntary payment is generally possible with conduct requirements that differ by jurisdiction. These accounts need a defined path counsel has approved.

Key takeaways

  • The legal complexity is real; the operational failure is that nobody records the inputs, and that part is fixable.
  • A collector on a call cannot resolve a limitation question — it has to be a computed field they read.
  • "Unknown" is a status needing its own treatment, and a blank field looks the same as an established date.
  • A token payment on an aged account may do something significant, and the incentive structure points toward asking for one.
  • Price acquired portfolios for data quality on these fields, because it determines what they can lawfully be worked for.
  • Run a report on approaching dates — an account worth settling before one is worth nothing after.

Know what you're holding

Get started with HL Hunt AI Debt Collection for structured date and event capture, configurable status computation, status-driven routing across channels, and standing reporting on aged accounts.

Get Started with HL Hunt AI Debt Collection


This guide is educational and does not constitute legal advice, and it deliberately provides no jurisdictional periods or specific rules because these vary substantially by state and by obligation type and change over time. Determining which law applies, what the applicable period is, what events affect it, and what conduct is permitted on an aged account are questions requiring qualified counsel familiar with your portfolio and jurisdictions.