Asset Based Lending Software: Rebuilding the Borrowing Base Certificate Without Rebuilding It by Hand Every Week

The Tuesday morning that sets your advance rate

A borrower emails an accounts receivable aging at 8:40am. It is a PDF this week because someone exported it differently, and the inventory listing is a CSV whose column headers moved when they upgraded their ERP (Enterprise Resource Planning) over the weekend. The analyst opens last week's workbook, saves a copy with today's date in the filename, pastes the aging into the tab, spends twenty minutes repairing columns, applies the ineligibles, checks the dilution reserve, subtracts the rent reserve for the two warehouse states, arrives at availability, and releases the revolver draw at 11:20am.

That is three hours of a trained analyst for one borrower. Multiply by forty borrowers on a weekly cycle, some daily, and you have roughly one and a half full time people whose entire job is retyping other companies' data into Excel. The cost is not really the salary. The cost is that the borrowing base is the only thing standing between your advance rate and an unsecured position, and it is being maintained by copy and paste in a file that has been saved as a copy of a copy for six years.

The failure mode is quiet. Nobody notices a broken formula in row 340 of the ineligibles tab. It surfaces at a field exam, or at a monitoring visit, or worst, at a workout, when somebody asks how a borrower ended up with an over advance for four months and the answer is that a cross age rule stopped firing after a column was inserted.

Why the borrowing base is not really a calculation

A borrowing base is a legal definition that happens to produce a number. That distinction is the whole reason generic software struggles here.

Every credit agreement defines eligible receivables differently. Aging is cut at 90 days, but from invoice date in one deal and from due date in another. Cross age taints a debtor's whole balance at 25 percent in one agreement and 50 percent in the next. Concentration caps sit at 15 or 20 percent with named carve outs for investment grade account debtors. Foreign debtors are excluded unless supported by credit insurance or an acceptable letter of credit. Government receivables are out unless properly assigned under the Assignment of Claims Act. Then contras net against payables to the same party, credit balances get added back, unapplied cash is deducted, and disputed, bill and hold, progress billed and consignment items each get their own treatment.

Inventory is worse, because eligibility depends on an appraisal. Raw materials and finished goods advance against a net orderly liquidation value that an appraiser refreshes on a cycle, work in process is usually out entirely, in transit depends on who holds title, and the whole category sits under a sublimit that may itself step down over the life of the facility.

Layer on the dilution reserve, computed from credits issued over sales on a rolling window that every agreement sizes differently, plus rent reserves in landlord lien states without a waiver, priority wage and tax reserves, and the discretionary reserve your credit committee sets because they do not like the customer concentration. There is no template here. There is a bespoke rule set per deal, negotiated by lawyers, and it changes with every amendment.

What Lendscape, Solifi, Cync and ABLSoft do well, and where they run out

These are real ABL platforms and we would not tell you to rip one out for sport. They handle the loan accounting side properly: the collateral ledger, daily cash application from a lockbox, interest and fee accrual, participations. If your problem is loan servicing, they solve it.

The constraint is on the analysis side, and it shows up in four places. First, ineligible definitions are configured against the vendor's template, so a clause your lawyers negotiated becomes a manual adjustment line. Manual adjustment lines are precisely what a field examiner circles, because nobody can tell you afterwards how the number was derived. Second, borrower file ingestion remains a per borrower mapping exercise done by hand, and it breaks every time a borrower changes ERP, adds a column or sends a PDF instead of a CSV. Third, the trail from a certificate line back to the specific invoices is usually not there, so when the examiner asks why 412,000 dollars came out as cross age ineligible in March, you rebuild it from files in a shared drive. Fourth, pricing is per user or per portfolio, which is reasonable for a bank ABL group and expensive for a specialty lender with 25 high touch borrowers.

If you run factoring alongside ABL, or you lend against collateral outside the standard receivables and inventory pair, you will end up half in the platform and half in Excel, which is the worst of both.

What a custom build has to include

Ingestion comes first and it is the part people underestimate. Accept the file the borrower actually sends: Excel, CSV, fixed width, a QuickBooks or NetSuite export, sometimes a PDF. Store every raw file permanently, because it is the evidence behind the certificate. Map columns per borrower with a saved mapping and, critically, a drift check that flags when the file shape changes instead of silently mapping the wrong column into the wrong field. Column header matching is a genuine and modest use of machine learning here: it proposes a mapping when a format shifts and an analyst confirms it once, which turns a twenty minute repair into a ten second click.

Then ineligibles as named, dated rules that cite the credit agreement section they come from. Not formulas in cells, rules in a registry, each with an effective date. When an amendment raises the concentration cap from 15 to 20 percent on 1 March, every certificate before that date still computes the old way forever. That single property is what makes the next feature possible.

Deterministic recompute is the feature that ends arguments. Ask for the certificate as at any past date and the system rebuilds it from the stored source files and the rule versions in force that day, producing exactly the number you published. When a field examiner questions an eligibility call from eight months ago, you show the invoices, the rule, and the agreement section, in about a minute.

Line level traceability sits alongside it. Click the cross age total and see the debtors and invoices that produced it, with the rule that caught each one. Analysts stop trusting the number because the model says so and start being able to defend it.

After that comes the monitoring layer, which is where a good build starts making credit decisions better rather than just faster. Dilution creeping up quarter on quarter. An account debtor approaching a concentration cap before it breaches. Aging buckets migrating rightward. Receivables growing while collections flatten, which is often the earliest visible sign of pre billing. None of this is exotic analytics. It is simply impossible when every certificate lives in a separate workbook.

Finish with the operational edges: a borrower portal that validates the file at upload so an aging that does not foot is rejected at 9am by the system rather than at 2pm by a person, a field exam workflow where findings become rule changes with an effective date and a named owner instead of a memo, and availability publishing with over advance alerts into whatever holds the loan.

What this costs and what moves the number

A first release covering ingestion for your main borrower formats, the rule engine with effective dating, deterministic recompute and certificate output runs $70,000 to $160,000 and ships in 12 to 18 weeks. That is a system your analysts use on Monday, not a prototype. The full platform with the borrower portal, exam workflow, trend monitoring, loan system integration and factoring support runs $180,000 to $400,000 phased across 6 to 12 months.

What pushes the number up: borrower count and format variety, because each new shape of file is real work. Inventory collateral with appraisal driven values, since net orderly liquidation value updates have to flow through history correctly. Running factoring alongside ABL, which brings notification, verification and a purchase ledger into scope. Multi currency. Integration into an existing loan accounting core, which is usually a file exchange rather than an API and needs reconciliation on both sides.

The largest and least visible driver is discovery. If your ineligible definitions exist only as formulas inside one analyst's workbook, someone has to sit with that analyst and write down what the agreement actually says versus what the spreadsheet actually does. Those two things diverge more often than anyone expects, and finding the gap is frequently the most valuable week of the project.

When buying is the right call

Buy if you carry under roughly 25 to 30 borrowers on fairly standard agreements, weekly reporting is fine, and your collateral is conventional receivables and inventory. Lendscape or Solifi will handle it and a custom engine would pull attention away from originating. Buy also if your real pain is loan accounting and cash application rather than collateral analysis, because that is exactly what those platforms are built for.

Build when at least two of these hold. Same day availability is why borrowers choose you over a bank, so the analyst cycle time is a commercial weapon rather than an overhead. Your collateral includes categories the platforms do not model cleanly, such as equipment, contract receivables or insurance receivables. You run factoring and ABL on the same book. Your agreements carry ineligible definitions that are genuinely negotiated rather than boilerplate. Or you have already been through a field exam, a covenant dispute or a loss where the certificate could not be reproduced, and you know what that cost.

How to choose a developer for this

Put cross age on a whiteboard and ask them to model it before you sign anything. If they cannot explain why a single past due invoice can taint an entire debtor balance, and why that threshold differs per agreement, they will build a filter and describe it as a rules engine. You will discover the difference at your next exam.

Ask what happens when an amendment changes an advance rate on the fifteenth of the month, and whether last month's published certificate still computes on the old terms. The correct answer involves effective dated rule versions, not a flag on a record.

Ask what happens when a borrower's file gains a column or arrives as a PDF. A developer who has done this will talk about schema drift detection and a human confirmation step. One who has not will say the import is configurable.

Ask about immutability directly. Raw borrower files, computed certificates and rule versions should be append only, because in a workout the certificate is a document your recovery position may rest on, and an editable history is not evidence.

Finally, settle ownership before kickoff. You should own the repository, the cloud accounts and every raw collateral file the system has ever received. That archive is your audit defence and it belongs in your infrastructure. At Digital Heroes the client owns the code and the data from the first commit, and we would tell you to walk away from anyone who wants to hold either.