What is a borrowing base certificate? A practical guide for finance teams

If your company borrows against its receivables, there is one document that decides how much cash you can actually draw this week. Not your financial statements. Not your AR aging. The borrowing base certificate. Most finance teams inherit the template from whoever built it years ago, and most lenders receive it as a spreadsheet someone assembled by hand the night before it was due. Let us walk through what this document really is, what belongs in it, and why so many of them quietly go wrong.

Why lenders require it

In an asset-based loan or receivables facility, the lender's protection is the collateral. But receivables move every day. Customers pay, new invoices post, some balances go past due, some get disputed. The lender needs a recurring, signed statement of what the collateral is worth right now, tested against the rules both sides agreed to in the credit agreement. The OCC's handbook on asset-based lending treats borrowing base monitoring as a core collateral control for exactly this reason, and notes that reporting can be required as often as daily for riskier collateral.

The signature matters as much as the math. When an officer signs the certificate, the company is attesting that the receivables exist, that the eligibility tests were applied correctly, and that the reserves match the agreement. That attestation is what the lender relies on between field exams.

What actually goes into one

• Gross accounts receivable as of the cutoff date, tied to your subledger.
• A roll-forward: prior balance plus new sales, minus collections, dilution, and write-offs, reconciling to the current balance.
• Ineligibles by category: invoices too far past due, cross-aged customers, excess concentration, intercompany balances, foreign receivables, disputes, and contras.
• Eligible receivables, which is what remains after every exclusion.
• The advance rate applied to eligibles, commonly 80 to 90 percent for receivables.
• Reserves: dilution, yield or interest, servicing, and anything facility specific.
• The punchline: net availability, which is the lesser of the borrowing base and the facility limit, minus what you have already drawn.

The calculation, start to finish

Here is a simplified version of the waterfall with real numbers, because the shape of the calculation matters more than any single line.

Every line above depends on rules defined in your credit agreement. A different aging cutoff, a tighter concentration cap, or a recalculated dilution reserve can move availability by millions without a single new invoice being issued. That is why two companies with identical receivables can have very different borrowing capacity.

Where certificates go wrong

In our experience the failures are rarely dramatic. They are quiet, and they compound.

• Stale data. The certificate is built from an export pulled days before submission, so it misses recent credit memos and cash.
• Inconsistent eligibility logic. Cross-aging applied one way in March and another way in April, because a formula changed and nobody noticed.
• Obligor identity gaps. The same customer spelled three ways, so concentration is understated.
• Roll-forwards that do not tie. The current certificate cannot be reconciled to the prior one, which is the first thing a field examiner checks.
• No traceability. When the lender asks why a number moved, the answer lives in someone's memory instead of in the data.

None of these are fraud. They are the natural result of running a control document through copy and paste. But the consequences are real: overadvances that must be repaid on short notice, tense field exams, and lenders who respond to uncertainty by adding reserves that shrink your availability.

Can the whole thing be automated?

Yes, and the interesting part is which half you automate. Reading messy data is a judgment problem: mapping ERP exports, PDFs, and spreadsheets into clean invoice level records. That is where AI helps. The calculation itself should never be probabilistic. Eligibility tests, advance rates, and reserves need to run deterministically, the same way every time, with each output traceable to the invoices and the rule that produced it. That split is how Olycor works: AI interprets the inputs, deterministic rules compute the certificate, and the output is signed and ready for your lender.

Availability is a conclusion. A certificate is only as good as your ability to defend every step that led to it.