Debt Collection Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the after the fact attempt log happen so often?

Almost every collection platform build starts from the same instinct: pull the dispositions from the dialer, pull the sends from the text platform, pull the mail file from the letter vendor, put them in one place, and report on the total. It sounds like the right project. It is the wrong direction of travel.

Recording an attempt after it happened is a receipt. What Regulation F needs is a gate. Seven call attempts within seven consecutive days per particular debt, plus the seven day cooldown after a telephone conversation, are limits that have to be checked before the dial, not counted after it. A system that reconciles nightly will tell you accurately that you broke the rule.

The reason teams land on the wrong side of this is sequencing. Ingesting dispositions is easy, ships in a fortnight and demos well. Making every channel ask permission first means the dialer becomes a dumb executor of an approved list, which requires renegotiating how your dialer is used and pushing back on a vendor integration that was built to run its own campaigns. That is uncomfortable work in week two of a project, so it gets deferred, and once the architecture assumes attempts arrive as batches it does not get undone cheaply.

The fix is to make the ledger the first thing built and the only writer. One append only record keyed on debt identifier, channel, timestamp, outcome, actor and client. Every dial request, every message, every limited content message asks it before going out. Write the acceptance test into the statement of work: with the ledger live, a revocation posted at 9:02pm must block the 4:15am campaign build without a human touching anything. If a proposal cannot describe how that works, it is a reporting project.

What goes wrong when a decade of account notes gets migrated?

Migration budgets in this category are almost always built around balances, and balances are the easy part. The hard part is account notes and attempt history, and they are not text. They are evidence.

A note written by a collector in 2019 may be quoted back to you in a deposition. It has an author, a timestamp, a debt it belongs to and a sequence relative to other events. If the migration flattens those notes into one blob per account, or rewrites timestamps into the migration date, or loses the distinction between a system generated entry and a human one, you have destroyed the record that your bona fide error defence depends on.

What we see go wrong, repeatedly:

• Author fields carrying a departed employee's identifier that no longer maps to anyone, so the note appears unattributed.
• Legacy systems storing local time with no zone, migrated into a system storing coordinated universal time, silently shifting an entire history by several hours and breaking the ordering of events on the days that matter.
• Attempt history migrated as a count rather than as events, which permanently destroys the ability to answer how many attempts occurred in a specific seven day window in 2023.
• Notes truncated at a field length that was larger in the old system.

The fix is unglamorous. Migrate notes and attempts as immutable events with original author, original timestamp, original time zone and a source system marker, and keep the raw extract in cold storage indefinitely. Then reconcile: pick fifty accounts across your oldest and newest clients, print the note history from both systems side by side, and have a supervisor who worked those accounts confirm they read the same. Do that before cutover, not after, and budget a parallel run through at least one full remittance cycle.

Why do dialer and payment integrations break after launch?

They break because they were built against a working state rather than against the failure states, and collection integrations fail constantly in ordinary operation.

The dialer is the common one. LiveVox, TCN, Noble, Convoso and Genesys all expose usable interfaces, and all of them will at some point return a disposition late, return it twice, or drop the connection mid batch. If your ledger writes are not idempotent, a redelivered disposition becomes a second attempt against a debt and your own compliance gate starts blocking legitimate calls. If they are idempotent but you do not reconcile, a dropped batch leaves attempts unrecorded and your gate lets calls through it should have stopped. Both directions cost you.

Payments break differently. Tokenised gateways such as Repay, Intelligent Contacts or PayNearMe are the right architecture, because card data never lands in your database and your Payment Card Industry scope stays small. The failure is the return. An automated clearing house payment reverses on day four, and if the build modelled a payment as a row that can be edited rather than as an event that can be reversed, the commission you already recognised and paid out has no clean path back. Every reversal then becomes a manual journal entry.

Design for it from the start. Every inbound message carries a source identifier and is processed exactly once. A scheduled reconciliation compares what the vendor believes it sent against what you recorded, and raises a named alert rather than a dashboard metric. Financial movements are events, never edits, so a reversal is a new entry with a link to what it reverses.

What happens when validation and dispute clocks are not covered?

The dispute is the most commonly underbuilt object in a collection platform, and it is the one that generates regulatory complaints.

Disputes arrive by post, through the consumer portal, as an automated consumer dispute verification through e-OSCAR, and as a sentence a collector typed into an account note at four in the afternoon. Four intake paths. One clock. In most builds a dispute is a status code, which means it has no owner, no service level, no attached evidence and no timer. Collection is supposed to stop on that debt until validation is mailed, the credit reporting record needs a compliance condition code, and the supporting media has to come from the creditor, which is an email to a client contact and a wait of unknown length.

The failure mode is worse than a missed deadline. It is mailing a wrong figure. The validation notice under Regulation F requires the itemisation date and an accurate breakdown as of that date, and if your placement record put the original creditor brand and the itemisation date into a user defined field, you cannot generate that notice from data and somebody retypes it. A retyped balance that does not match the creditor's statement is how a dispute becomes a lawsuit.

Build the dispute as a case object with a single intake regardless of channel, a clock that starts on receipt rather than on data entry, a hard block on outbound attempts for that debt while it is open, an automated media request to the client naming the exact documents needed, and a validation packet generated from stored structured fields. Then reconcile the creditor's returned statement against your placement record automatically and flag the mismatch before anything is mailed.

Should you build custom or configure what you already own?

Below roughly twenty five collectors, working one debt type for a handful of clients who accept your standard reporting, configure. CollectMax, Debtmaster or InterProse ACE will outrun anything you build at that size, and the money is better spent on skip tracing data and people. We would tell you that rather than take the work.

The same applies if the pain you feel is really a configuration gap. Plenty of agencies run Finvi Artiva or Columbia Ultimate at a fraction of what those platforms can do, with rules that were set at implementation years ago and never revisited. Before commissioning a build, have someone competent audit what your current system can already enforce, because replacing a platform to get behaviour you had not switched on is an expensive way to learn.

Build when the signals are concrete. Two or more full time people exist only to move files between systems. New client onboarding takes more than four weeks and the delay is the file format, not the contract. You lost a bid because you could not report the way a creditor wanted. Your compliance posture is set by a dialer vendor's roadmap. Or your largest client's rules live in one supervisor's head.

Even then, build the layer, not the stack. Keep the dialer, the payment gateway and the letter press, and build the account model, the attempt ledger, the decision engine, the dispute cases and the client facing ledger above them. That is the difference between a first release and a multi year programme.

How do hidden costs get into the quote?

Five items account for most of the overruns we see, and none of them are surprises if you ask.

Client specific formats priced as one integration. Each creditor brings a placement file, a recall file, a close file and a remit format, and the eleventh client costs roughly what the third did. Price per client, not per project.

Credit reporting treated as an export. Metro 2 output and dispute handling through e-OSCAR is unforgiving and the dispute path has to be exact. It is a module with its own budget line, and quotes that mention it in a bullet have not scoped it.

Audit logging retrofitted. If who changed which rule and when is not designed in from day one, adding it after launch means touching everything. This is one of the most common cost overruns in the category, and the audit trail is your defence, so it is not optional.

The state rule matrix. Licensed in thirty plus states means disclosure text, cadence limits and interest treatment varying by jurisdiction, held as versioned configuration your compliance officer can edit without a release.

The parallel run. Nobody cuts a collection floor over in a weekend. Budget the double running, the reconciliation work and the temporary drop in collector productivity, because it is real cost that appears in no proposal.

What separates a build that works from one that fails here?

Make them draw the data model before you sign. Debt, consumer, account relationship, placement, attempt, consent event, dispute case, financial transaction. If consumer and debt are one entity, or attempts are a counter rather than an event log, they have never built this and your budget is paying for their education.

Ask which integrations they have run in production, by name, and what broke. A dialer interface, a tokenised gateway, Metro 2 output, TLOxp or Accurint, a bankruptcy scrub feed. The right answer contains a war story. Vague talk about integration capability means your first three months are discovery on your money.

Ask how a compliance rule gets changed. If the answer involves a code change and a release, keep looking. Cadence limits, disclosure text and state rules belong in versioned configuration with an audit trail of who changed what and when.

Settle ownership and exit in the contract, not at kickoff. You own the repository, the schema and the deployment in your own cloud account from the first commit, which is how Digital Heroes ships, and you get a runbook plus a named plan for taking the team down to a maintenance retainer. A partner who resists that is selling a subscription with extra steps.