Unclaimed Property Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as reporting when the risk is identification?

Ask a compliance lead what unclaimed property costs and you will hear about the autumn deadline: files per state, due diligence letters, negative reports where required. That work is real, it is stressful, and it is the part with a visible date attached, so it is the part that gets scoped.

The money is earlier and quieter. Uncashed accounts payable cheques going back years. Terminated employees with final payments never presented. Customer credit balances in accounts receivable that were written off to income, which is the single most common audit finding. Unredeemed rebates, customer deposits, unclaimed dividends and shares belonging to people the transfer agent stopped reaching in a year nobody remembers. Those items sit in six systems with different owner keys and no shared concept of a last contact date, and no reporting tool reaches into them.

The fix: scope identification first and reporting second. The first release should pull candidate property out of each source ledger with lineage back to the originating transaction, apply a versioned dormancy rule, and hold the result as a determination with its inputs. Reporting then becomes an output of a defensible population rather than a population assembled to satisfy a report. If the budget only covers one of the two, cover identification, because that is the half an auditor tests.

What goes wrong with the source ledger data?

Three specific things, and none of them is fixed by better software alone. First, the owner key differs everywhere. A vendor in payables, an employee in payroll, a customer in receivables and a registered holder in the stock records are four different identifiers for what may be one person, and there is no shared field to join on. Second, an outstanding item means different things in different ledgers. A stale dated cheque in one system is voided and reissued, in another it sits open forever, and in a third it was written off to income in a batch that removed the underlying detail. Third, and most damaging, nobody records when the owner last did something. Systems can tell you the last transaction on an account, which is not the same question and not the one dormancy turns on.

The fix: define contact events explicitly per property type before extraction, then capture them from the systems that actually observe them: a cashed cheque, a logged in session, a call to the service centre, a returned envelope. Store returned mail as its own dated event so address status becomes a tracked attribute rather than a guess. Where an item was written off to income, keep the write off as a reversible event with its detail rather than a net entry, because that detail is exactly what you will be asked to produce. This is unglamorous plumbing and it is the difference between a population you can defend and one you reconstruct under pressure.

Why do the source system connections break after launch?

Because they were built as extracts against a moment in time. Then the general ledger is upgraded and the account structure changes, or a subsidiary is acquired onto a different receivables system, or someone in finance improves the write off process and the field the extract depended on stops being populated. The extract keeps running and keeps returning fewer items, which looks like good news.

Silent under collection is the characteristic failure of this category. Nothing errors. The property count simply drops, and it drops in the direction that feels like progress, so it survives every review until an auditor samples the population and finds items that were never evaluated.

The fix: monitor the population, not the job. Alert on volume by source system and by property type against the trailing period, so a drop is an exception with an owner rather than a quiet improvement. Reconcile the extracted population back to a control total in the source ledger each cycle and record the reconciliation. When a source system changes, treat the extract as in scope for that change control on your side, and name the person responsible. Keep the raw extract untouched as evidence alongside the normalised records, because in a dispute about what a system contained on a date, the original file is the record that matters.

What happens when due diligence evidence and holder reimbursement are not covered?

Most states require an attempt to reach the owner before property is reported, with their own thresholds, windows and content requirements. Holders do the mailing. What they cannot produce two years later is proof that a specific letter went to a specific address on a specific date, or the record of the owner response that removed an item from the report. The letter was generated, printed, posted, and nothing about that sequence was retained in a form anyone can query.

Holder reimbursement is the other routinely forgotten workflow, and it involves real money. Property is reported and remitted. Later the owner appears at your door, and you make them whole and file to recover from the state. If nothing links the payment you just made to the property you remitted three years ago, that reimbursement claim becomes a manual archaeology exercise, and some of them simply never get filed.

The fix: run due diligence as campaigns with per state rule sets, retaining the generated letter, the address it went to, the date, the returned mail and the owner response linked to the property record. Responses should reduce the report automatically with the reason stored. Build reimbursement as a first class workflow from day one, since it is the one part of this system that returns cash rather than avoiding cost.

Should you build custom or configure what you already own?

If you are a single legal entity reporting a few hundred properties a year across a handful of states, do not build. Eagle Technology Management's UPExchange plus a written checklist and a named owner is proportionate, and it prepares state files and due diligence letters competently. Sovos covers holder compliance reporting inside a broader regulatory portfolio, which suits organisations already standardised on it. On the administrator side, Kelmar works extensively with states on both systems and audit services.

None of those reaches into your payables, payroll, receivables and stock records to identify property with lineage, and none holds your dormancy determinations as versioned reproducible decisions across a decade of audit reach. That is the gap, and it is why holders buy the reporting tool and keep the identification work in spreadsheets, which is precisely where audits find their money.

Build the identification and evidence layer and keep the reporting tool if it works. Build the whole thing when you file across many states from several legal entities, when you hold securities property, when your receivables credit balances have historically been written off to income, or when you have received an audit notice and evidence production has become the priority.

How do hidden costs get into the quote?

Entity and state count is the first, because exposure is a matrix rather than a list and each additional combination brings its own dormancy periods, thresholds and due diligence rules. Source system count is the second, since each ledger has its own definition of an outstanding item and its own extraction work. Securities property is the third and is genuinely a separate workstream: shares escheat, states commonly liquidate them, and a claimant can appear years later with a view about what the position would be worth now, which a cash report cannot represent.

Historical loading is the fourth and the one most often assumed away. The value of the system is a function of how far back it can reproduce a determination, and loading history means finding, interpreting and evidencing data from systems that have since been replaced. Being under audit already is the fifth, because it reorders everything: evidence production for specific sampled properties outranks prevention, and the project you scoped is not the project you now need.

The fix: ask for the price broken by entity, by state group and by source system, then ask what changes if securities come in scope and if you need ten years of history rather than three. Ask who on your side owns the reconciliation to source ledger control totals each cycle.

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

Ask them to draw the model: source transaction, property, owner, address with status, contact event, dormancy rule version, due diligence attempt with evidence, report submission, remittance, claim, decision, payment. If they cannot explain why the rule version has to be stored on the property rather than looked up at query time, they will build something that cannot answer a question about a determination made six years ago, which is the only kind of question an auditor asks.

Ask about the priority rules and what happens to a property with no usable owner address. Anyone who has worked in this domain raises state of incorporation without prompting, and understands why a company incorporated in Delaware carries exposure on every record with a bad address regardless of where the customer lived. Ask how a property already reported and remitted is handled when the owner appears. Holder reimbursement is real money and it is routinely missing from scope.

If you are on the state side, ask how evidence requirements per claim type are expressed. An individual claim on a bank account, an heir claim needing death evidence and a relationship chain, and a business claim on a dissolved entity needing successor documentation are three different evidence sets, and they belong in configuration rather than in staff knowledge. Then settle ownership before kickoff: the repository, the infrastructure accounts and the right to hire another firm. Audit reach in this field is measured in decades, and the system holding your determinations has to outlive whoever built it.