Asset Based Lending Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do ineligible rules end up trapped in spreadsheet formulas?

Because the borrowing base is a legal definition that happens to produce a number, and nobody scopes it that way. The project brief says: calculate availability. So a developer builds a calculator, the analyst maps their existing formulas into it, and the result is the same workbook with better fonts.

What the brief missed is that every credit agreement defines eligibility differently. Aging is cut at 90 days from invoice date in one deal and from due date in the next. Cross age taints a debtor's entire balance at 25 percent in one agreement and 50 percent in another. Concentration caps sit at 15 or 20 percent with named carve outs for investment grade account debtors. Foreign debtors are out unless supported by credit insurance or an acceptable letter of credit. Government receivables are out unless properly assigned under the Assignment of Claims Act. Contras net, credit balances add back, unapplied cash deducts, and bill and hold, progress billed and consignment items each get their own treatment.

None of that is a formula. It is a bespoke rule set per deal, negotiated by lawyers, amended over the life of the facility.

Build it as a registry of named, dated rules that cite the credit agreement section they come from. Each rule carries an effective date, so when an amendment raises a concentration cap on 1 March, every certificate before that date continues to compute the old way permanently. Put cross age on a whiteboard during vendor selection. A developer who cannot explain why one past due invoice taints a whole debtor balance, and why the threshold differs per agreement, will build you a filter and call it a rules engine.

What goes wrong when borrower collateral files change shape?

They change constantly and they change without warning. A borrower upgrades their enterprise resource planning (ERP) system over a weekend and the column headers move. Someone in their accounting office exports differently and the aging arrives as a PDF this week. A new debtor naming convention appears. A subtotal row gets included that was previously stripped.

The failure that matters is not the twenty minutes of repair. It is the silent version, where a mapping still resolves and now puts the wrong column into the wrong field. Current balances land in the past due bucket, or a credit memo column reads as an invoice column, and the certificate computes cleanly to a number that is wrong. Nobody catches it because nothing broke.

Two things prevent it. Store every raw file permanently and unaltered, because the raw file is the evidence behind the certificate and you will want it in an exam. And run schema drift detection on every ingest, so a changed file shape raises a flag and a human confirms the new mapping once rather than the system guessing forever. Column header matching is a reasonable and modest use of a model here: it proposes the new mapping and an analyst accepts it in seconds.

Ask a developer what happens when a file gains a column. Someone who has done this talks about drift detection and a confirmation step. Someone who has not says the import is configurable.

Why do loan accounting and cash application integrations break after launch?

Because the connection between a collateral analysis system and a loan accounting core is almost never a clean interface. It is usually a file exchange on a schedule, and file exchanges fail in ways that look like success.

The recurring problems are specific. Availability publishes to the loan system but the acknowledgement is never checked, so a failed file leaves yesterday's availability in place while your analyst believes the update landed. Lockbox cash application posts against invoices that the collateral file has since renumbered, producing a reconciliation difference nobody owns. Reserve amounts get applied in one system and not the other after an amendment. And nothing alerts, because the job completed.

The fix is to treat every exchange as a two sided reconciliation rather than a send. Both systems report a total and a record count, the difference is computed automatically, and a non zero difference becomes an exception with an owner and a deadline rather than a line in a log. Over advance alerts should fire from the reconciled position, not from the position you sent.

This is unglamorous work that gets cut from scope when the budget tightens, and it is the single most common reason an otherwise good build produces numbers people stop trusting in month five.

What happens when field exam findings and audit evidence are not covered?

A field exam produces findings, and findings change how collateral is treated: an ineligible category gets broadened, a reserve gets added, a dilution calculation window changes. In most lenders that outcome travels as a memo, and somebody edits the workbook. The memo is filed. Six months later nobody can connect the current rule set to the exam that produced it.

The second half of the gap is line level traceability. When an examiner asks why 412,000 dollars came out as cross age ineligible in March, the answer needs to be the specific debtors and invoices, the rule that caught each one, and the agreement section that rule cites. Without that, the answer is an afternoon of rebuilding from files in a shared drive, and the examiner has already formed a view about your controls by the time you produce it.

Cover both structurally. Exam findings become rule changes with an effective date, a named owner and a link back to the exam that generated them. Every certificate line drills through to the underlying records. Raw files, computed certificates and rule versions are append only, because in a workout the certificate is a document your recovery position may rest on, and an editable history is not evidence. Ask about immutability directly during selection. It is a design decision, not a feature you add later.

Should you build custom or configure what you already own?

If you run under roughly 25 to 30 borrowers on fairly standard agreements, weekly reporting is acceptable, and your collateral is conventional receivables and inventory, configure HPD Lendscape or Solifi properly and get back to originating. They are real asset based lending platforms and they handle the servicing side well: collateral ledger, daily lockbox cash application, interest and fee accrual, participations. If your actual pain is loan accounting rather than collateral analysis, that is exactly what they were built for and a custom engine would be a distraction.

Where they run out is the analysis side. Ineligible definitions get configured against the vendor's template, so a clause your lawyers negotiated becomes a manual adjustment line, and manual adjustment lines are precisely what an examiner circles. Borrower file ingestion stays a per borrower mapping exercise done by hand. The trail from a certificate line back to specific invoices is usually not there. Cync and ABLSoft sit in similar territory with different strengths.

Build when at least two hold. Same day availability is why borrowers choose you over a bank. Your collateral includes categories the platforms do not model cleanly, such as equipment or contract receivables. You run factoring and asset based lending on the same book. Your ineligible definitions are genuinely negotiated rather than boilerplate. Or you have already been through an exam where the certificate could not be reproduced.

How do hidden costs get into the quote?

Format variety is the first, and it is priced by borrower count when it should be priced by file shape. Forty borrowers sending eleven distinct formats is a different project from forty borrowers sending three. Ask for a sample set to be examined before a number is quoted.

Inventory collateral is the second. Appraisal driven values mean net orderly liquidation value updates have to flow through history correctly, which is more work than storing a percentage. Sublimits that step down over the facility life add another dimension.

Factoring is the third, and it arrives as an assumption rather than a line. It brings notification, debtor verification and a purchase ledger into scope, and it is meaningful build rather than a configuration switch. Scope it explicitly.

Discovery is the fourth, and it is the largest and least visible. If your ineligible definitions exist only as formulas inside one analyst's workbook, somebody has to sit with that analyst and write down what the agreement says versus what the spreadsheet does. Those two diverge more often than anyone expects, and finding the gap is frequently the most valuable week of the project. It is also a week that never appears in a fixed price proposal unless you ask for it.

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

The ones that work make the rule registry and effective dating the foundation rather than a phase two enhancement. Retrofitting effective dates onto a system that stored current rules is a rewrite, and you will need them the first time an amendment lands.

They store the source file, not just the parsed data. Analysts stop trusting a number because the model produced it and start being able to defend it, which changes the culture of the credit team more than any dashboard.

They run parallel for a full reporting cycle on your three most complex borrowers rather than your three easiest, because the easy ones tell you nothing. Differences between the workbook and the new engine are the point of the exercise, and roughly half of them will be the workbook being wrong.

And they settle ownership before kickoff. You should hold the repository, the cloud accounts and every raw collateral file the system has ever received. That archive is your audit defence and potentially your evidence in a recovery, so it belongs in your infrastructure rather than a vendor's. At Digital Heroes the client owns the code and the data from the first commit, and any developer hedging on either is building a dependency you will pay for at renewal.