Insolvency Administration Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the statutory diary get scoped as a task template?

Almost every insolvency software proposal contains a line about tracking key dates, and almost every one of them means a checklist copied onto each new case. That is the biggest scope failure in this category, and it looks reasonable until the first extension is granted.

An administration, a liquidation, a bankruptcy and a receivership are not the same case with a different label. Each carries its own sequence of statutory acts, its own reporting intervals, its own extension mechanisms and its own consequences for a missed date. In England and Wales much of this sits in the Insolvency (England and Wales) Rules 2016, with progress reports running on fixed anniversaries of appointment. A Chapter 7 trustee in the United States operates under an entirely different structure with its own reporting to the United States Trustee. A practice working in both is running two rulebooks, and a copied checklist expresses neither.

What a template cannot do is recalculate. When the court grants an extension, when a criminal matter tolls a period, or when an order moves an anchor date, every dependent date should move with it and the practitioner should be told which ones changed. A template requires a human to remember the dependencies, which is precisely the exposure the software was bought to remove.

Specify it as generation, not entry. On appointment the system instantiates the correct statutory task set for that regime, computed from the appointment date and the case facts, with each generated date carrying the rule that produced it. A junior asking why a report is due on a particular day gets a citation rather than a convention. This is the least glamorous part of the build and the part where personal liability actually concentrates.

What goes wrong when you migrate live appointments?

You cannot pause an administration while you move it. That single fact makes migration in this category harder than in almost any other, and it is the workstream most often quoted as a data load.

Three things surface every time. First, estate balances have to agree in both systems on the cutover date, to the unit, per bank account, which means the reconciliation problem you are buying software to fix has to be solved manually once before the software can help. Second, the claim ledger carries adjudication decisions made months or years earlier by people who may have left, and the reasons for those decisions are frequently in correspondence rather than in a field. Loading a claim as admitted without its basis produces a ledger that cannot defend itself. Third, diary dates in the old system may have been maintained by hand, so importing them imports the errors. Regenerating dates from rules on import will disagree with what the case file says, and every disagreement needs a human decision.

Do it case by case with parallel running and a reconciliation sign off before each cutover, never as a single event. For a practice with a substantial live caseload this commonly runs alongside development for months rather than following it, and it consumes practitioner and cashier time rather than developer time. Budget it as its own line, staff it deliberately, and start with closed or nearly closed cases so the process is proven before a live trading administration moves.

Why do estate bank feeds break after launch?

Estate accounts often sit with specialist providers whose feeds are not standard, and that is where post launch failures cluster. The connection rarely dies outright. What happens is quieter: a statement file arrives with a changed column, a reference format shifts so automatic matching stops finding transactions, a new account is opened for a case and nobody adds it to the feed configuration, or a currency account starts reporting in a way the matcher did not expect.

The damage is delayed because reconciliation failures accumulate silently. A cashier assumes unmatched items are timing differences, they age, and by the time anyone investigates there are three months of them across eleven estates.

The design that survives this is unglamorous. Validate the shape of every inbound file and quarantine anything unexpected rather than importing it optimistically. Surface unmatched items with an age, per estate, on a screen someone looks at daily rather than in a report someone runs monthly. Alert when an estate has received no bank activity for a period that would be unusual for that case, because silence is the failure mode nobody notices. And make new account creation a workflow that includes the feed configuration, so an account cannot exist in the ledger without someone deciding how it will be reconciled.

What happens when claim assignment and duplicates are not covered?

At volume, claims do not arrive once and sit still. The same debt turns up twice because a creditor submitted by post and then by email. A solicitor submits on behalf of a client who has already submitted directly. A factoring company claims a debt the original supplier is also claiming. A government department claims in a preferential class and again in an unsecured one for a different component. A landlord claims an amount that includes future rent.

Software that treats each submission as a separate claim record turns all of this into a distribution problem. The system must record an assignment as a transfer event on the existing claim, preserving the original submission, the adjudication decision and the full history, with the new holder recorded from the effective date. Duplicates need a merge that keeps both submissions visible as evidence while collapsing them to one claim for distribution purposes, with the person who merged them and their reason recorded.

The other half of this gap is ranking. Admission is only half the decision. A claim has to be ranked into the correct class, and the classes come from the regime rather than from your preference. Distribution against a ranked ledger with a prescribed fund and a defined order of priority is arithmetic. Distribution against a flat list of admitted claims is guesswork, and it is the point at which practitioners go back to Excel for the one calculation they are personally liable for.

Should you build custom or configure what you already own?

Configure, and do it without regret, if you are a practice working in one jurisdiction with conventional appointment types and creditor volumes in the ordinary range. Turnkey IPS was built specifically for this profession and covers the statutory apparatus properly, and no bespoke build will reach that depth for the money. If your work is large corporate cases with mass claims administration and noticing, Stretto and Epiq exist because that scale is a specialised operation, and outsourcing it is frequently the commercially sound choice rather than a compromise.

Build when two or more of these are true. You take appointments under more than one regime or in more than one jurisdiction and your current system covers one properly. Your distribution waterfalls include structures a standard priority ordering does not express, which is common where security packages are layered or an estate spans entities. Consumer creditor volumes are capping how many appointments you can accept. Your cashier team reconciles estate accounts through a general bookkeeping package with a chart of accounts per case. Or you are already doing adjudication and distribution modelling in a spreadsheet, which is the clearest signal of all, because that is the work you carry personal liability for.

How do hidden costs get into an insolvency software quote?

The omissions are consistent enough to check for line by line.

• Each additional regime. Diary rules, priority ordering and reporting formats are regime specific. Two regimes is a second rule set, not a configuration option on the first.
• Bank integration. Estate accounts sit with providers whose feeds vary. Every provider is its own mapping, matching and exception handling problem.
• Creditor volume. A case with fifty creditors and a case with fifty thousand are different engineering problems, particularly for noticing, proof of service and portal load.
• Live case migration. Parallel running with per case reconciliation sign off, over months, consuming your staff rather than the developer's.
• Statutory report formats. Generating a receipts and payments account in the required format from a ledger is real work, and each format is separate.

For orientation, Digital Heroes delivery experience puts a focused first release covering case progression against generated statutory diaries, claim capture and adjudication, and the estate ledger with receipts and payments at $90,000 to $180,000 over 14 to 20 weeks, with a full platform at $250,000 to $550,000 phased over 9 to 15 months. The number of regimes you work in drives the cost more than the number of cases you handle.

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

Ask how a statutory date is calculated and what happens when it moves. The answer must describe rules attached to appointment type and regime, dates generated with the rule recorded, and cascade recalculation when an extension is granted. If the proposal is a task template someone copies per case, you have bought a shared to do list and you will still be checking dates by hand.

Ask how they model a claim assigned to a third party halfway through the case. A transfer event on the existing claim is the only correct answer. A second claim record means the distribution will double pay, and you will find out after the funds have gone.

Ask about the estate ledger specifically. Multiple bank accounts per estate, dual authorisation on payments, statutory classification on every posting, and a receipts and payments account generated from the ledger rather than formatted by a cashier. Then ask to see how unmatched bank items are surfaced and aged, because that screen is where reconciliation either happens or quietly stops.

Finally, settle ownership in writing before kickoff: the repository, the infrastructure accounts and an unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. Cases can be reviewed years after closure and the practitioner carries personal liability for the records, so a system you could lose access to through a commercial dispute is a risk that sits with a person rather than with a company.