The receivables finance reporting field guide

Every facility secured by receivables runs on the same bargain. The lender funds against invoices it will never touch, collect, or see shipped. In exchange, the borrower proves, period after period, that the collateral is what the agreement says it must be. The proof is the reporting layer: a small family of documents that translate a messy AR ledger into numbers a credit agreement can act on.

The documents differ by facility type, but they answer the same four questions. What receivables exist? Which ones qualify? What can be funded against them? And did the portfolio behave the way the deal assumed it would? Get those answers right, on time, and traceable to source, and the facility runs quietly. Get them wrong and you meet the remedies section of your agreement.

The borrowing base certificate is the load-bearing document of ABL. It is one page of arithmetic backed by thousands of invoice level decisions, and an officer of the company signs it as a representation to the lender. The structure is always a waterfall: start with gross AR, remove what the agreement disqualifies, advance against what remains, deduct reserves, cap at the commitment, and subtract what is already drawn.

Here is the full walk on a $30 million ledger with an 85 percent advance rate.

Read it bottom up and the stakes are clear. This borrower can draw $6 million more. If the ineligibles were understated by even 2 percent of gross AR, roughly $600,000, the borrowing base is overstated by $510,000 at the advance rate, and the borrower may already be overadvanced without knowing it.

Two tie-outs decide whether a certificate survives scrutiny:

• The aging tie. Gross AR on the certificate must equal the AR aging total, which must reconcile to the general ledger control account as of the same date. If the certificate says $30,000,000 and the aging says $30,180,000, everything downstream is suspect.
• The prior certificate tie. This period's beginning AR must equal last period's ending AR, bridged by the roll-forward covered below. A gap here means activity happened between snapshots that no report captured.

Everything else on the certificate is calculation. These two ties are evidence, and they are the first things a field examiner checks.

The philosophical difference is where the protection lives. ABL protects the lender through eligibility and lender-set reserves, then verifies through exams. Securitization protects investors structurally: the seller transfers receivables to a bankruptcy remote entity, and credit enhancement, dynamic reserves, and amortization triggers recompute from portfolio performance every period. That makes the securitization report more mechanical and less forgiving. A ratio is a ratio, and if the three month average crosses the trigger, consequences follow automatically.

The securitization funding calculation follows a fixed sequence:

Most reporting failures are data failures. The rules in a credit agreement are demanding but knowable; the hard part is feeding them fields that mean what the agreement assumes they mean. Ten fields carry nearly all of the weight, and each has a characteristic way of going wrong.

Eligibility is where the credit agreement meets the invoice file. Every open invoice is tested against each criterion, and only invoices that pass all of them enter the eligible pool. The recurring tests:

• Aging cutoffs. Invoices past a threshold drop out, commonly 90 days from invoice date or 60 days past due. Watch which anchor your agreement uses; a 90 day term invoice is fine under one convention and ineligible under the other.
• Cross-aging. If too large a share of one obligor's balance is past due, often 25 or 50 percent, the entire obligor becomes ineligible, current invoices included. The logic: an obligor that is half delinquent has a payment problem, not an invoice problem.
• Obligor exclusions. Intercompany and affiliate balances, government obligors, obligors in bankruptcy, and foreign obligors outside permitted jurisdictions are commonly excluded or capped.
• Disputes and offsets. Disputed invoices, contra accounts where you also owe the customer, and balances subject to setoff usually fail.
• Concentration. Exposure above a per obligor cap is excluded as excess concentration, covered in the next section.

Order of operations matters more than people expect. Aging and obligor tests run first at the invoice level. Cross-aging runs at the obligor level using the full obligor balance. Concentration runs last, against the pool that survived everything else, because a cap expressed as a percentage needs a base to be a percentage of.

A worked case shows why cross-aging stings. An obligor owes $2,000,000 across ten invoices, of which $1,100,000 is more than 90 days past due. The straight aging test removes $1,100,000. But $1,100,000 is 55 percent of the balance, over a 50 percent cross-aging threshold, so the whole $2,000,000 goes ineligible. The extra $900,000 of perfectly current invoices costs $765,000 of availability at an 85 percent advance rate. Thresholds vary by facility, so check yours before assuming either number.

A receivables pool that is 40 percent one customer is not a pool; it is a single credit exposure with extras. Concentration limits cap how much of the eligible base any one obligor, or group of related obligors, can contribute. Caps of 10 to 15 percent are common for ordinary obligors, with higher negotiated caps for investment grade names.

The mechanics are simple once you fix the base. Suppose the eligible pool after all other tests is $20,000,000 and the cap is 10 percent. Obligor A's eligible balance is $3,000,000, which is 15 percent of the pool. The cap allows $2,000,000, so $1,000,000 is excluded as excess concentration. At an 85 percent advance rate, that excess costs $850,000 of availability, even though every one of Obligor A's invoices is current and undisputed.

Two details trip people up. First, the base: most agreements compute the cap against eligible receivables before concentration exclusions, but some define it against the post-exclusion pool, which makes the calculation iterative. Read the definition, do not assume. Second, grouping: the cap applies to the obligor group, so three subsidiaries of one parent share a single cap. If your obligor master has no parent mapping, you are almost certainly understating concentration.

Excess concentration is also the exclusion borrowers can actually manage. Landing one large new customer is great for revenue and bad for the borrowing base until either the cap is renegotiated or the rest of the pool grows around it. Knowing the number before month end lets treasury plan for it.

Eligibility removes invoices that fail today. Reserves protect against what the surviving pool might do tomorrow: get credited away, default, or take too long to convert into cash while interest accrues. Three reserves do most of the work.

• Dilution reserve. Covers non-cash erosion of AR: credit memos, returns, rebates, pricing adjustments, and disputes settled by credit. Sized from the historical dilution ratio, usually a 12 month average, often multiplied by a stress factor.
• Loss reserve. Covers obligor defaults, sized from write-off and default history, frequently with a floor so a lucky year cannot zero it out.
• Yield and servicing reserve. Covers the interest and servicing cost that accrues while receivables convert to cash, so the collateral covers carrying cost as well as principal. It scales with rates and with DSO.

Here is a compact reserve stack on one consistent pool of $20,000,000 eligible receivables.

That is $2,350,000, or 11.75 percent of the pool, gone before the advance rate even applies. Reserves are commonly the least understood line on a certificate and the most common source of month to month availability surprises.

The floor versus dynamic distinction matters most in securitizations. A dynamic reserve recomputes each period from actual ratios: dilution spikes, the reserve grows, funding shrinks, automatically. A floor sets the minimum the reserve can reach no matter how well the portfolio performs. In the table above, the dynamic dilution calculation of 8 percent would beat a 5 percent floor, so the dynamic number binds. In a clean quarter the floor binds instead. Most agreements take whichever is greater.

The aging is a snapshot; the roll-forward is the movie between snapshots. It bridges beginning AR to ending AR through four flows, and it must tie exactly:

Beginning AR + Sales − Collections − Dilution − Write-offs = Ending AR

The $30,000,000 ending balance is the same gross AR that opens the certificate waterfall in section 2. That is the point: the roll-forward is what connects one certificate to the next, and it is how a reviewer confirms that nothing moved between reports without being accounted for. It also produces the dilution ratio as a byproduct: $650,000 of dilution against $9,800,000 of sales is 6.6 percent this period, a number your dilution reserve calculation will want.

The silent killer here is unapplied cash. A customer wires $400,000 against forty invoices and the payment sits in a suspense account for a week while someone works out the remittance detail. During that week, the forty invoices remain open and keep aging. Some cross the 90 day cutoff and fall out of eligibility, availability drops, and the roll-forward shows collections lower than the bank statement. The receivables were paid; the reporting says they went bad. Phantom aging is a cash application problem wearing an eligibility costume, and the fix is operational, not analytical: apply cash fast and flag suspense balances explicitly in the reporting.

In a trade receivables securitization the seller usually keeps servicing the receivables, and with that role comes the monthly servicer report. A typical report covers, at minimum:

• Pool balance and composition: obligors, currencies, aging distribution as of the cutoff date
• Activity for the period: sales, collections, dilution, write-offs, repurchases
• Eligibility and excess concentration calculations, arriving at the net receivables balance
• Required reserves and enhancement, and the resulting funding capacity or borrowing base
• Performance ratios and every trigger test, stated pass or fail

Three ratios carry the surveillance weight, and most programs test them as three month rolling averages so a single odd month does not trip a trigger:

• Delinquency ratio. Receivables in a defined past due bucket, commonly 61 to 90 days, divided by the pool balance.
• Default ratio. Receivables that aged into the default bucket or were written off during the period, divided by sales in the origination period that produced them.
• Dilution ratio. Credit memos and other non-cash reductions divided by sales, the same figure the roll-forward produces.

Trigger tests compare each ratio to a negotiated level. Breach one and the deal shifts posture: reserves step up, the reinvestment of collections stops, or the facility begins amortizing. Because the consequences are automatic, precision matters. A servicer report is not a narrative document. It is a calculation the structure executes, and an error in either direction is expensive: overstate a ratio and you trigger an amortization event that did not happen; understate it and you have misreported to investors.

Lenders verify receivables collateral in two rhythms. Continuously, a portfolio manager or credit analyst reviews each submission: does gross AR tie to the aging, do the trends make sense, why did eligible receivables move $2 million against last month, why did dilution jump. Periodically, a field exam goes deeper. Examiners sample invoices and trace them to shipping documents and cash receipts, re-run eligibility tests independently, recompute dilution from credit memo history, confirm account balances with obligors, and reconcile the roll-forward across the exam period.

Every variance question has the same anatomy: a summary number moved and the reviewer needs the detail underneath. In a spreadsheet workflow the answer is archaeology. Someone reopens the workbook, finds the relevant tab, hopes the version that produced the certificate still exists, and reconstructs the delta by hand. Each answer takes hours, and each hour of delay reads, fairly or not, as a control weakness.

Source-level traceability changes the transaction. When every value on a certificate carries lineage, the reviewer can independently decompose the $2 million move into its parts: which invoices aged out, which obligor crossed a concentration cap, which rule version applied, which file and row each input came from. The question that took a week of back and forth becomes something the reviewer answers without asking. Field exams still happen and lender review still governs, but exams against traceable reporting run faster, sample less blindly, and end with fewer findings. Over time that shows up where it counts: in reserves the lender no longer feels compelled to pad, in cadence requests that stay monthly, and in a relationship where the numbers are debated on substance rather than provenance.

Olycor is borrower-side software for exactly the layer this guide describes. It ingests receivables data in whatever shape it exists: ERP exports, CSVs with inconsistent headers, PDFs, spreadsheets, and emailed statements. An AI layer interprets that mess into a canonical invoice model, matching obligor names into legal entity groups and flagging anything ambiguous for a human decision. The calculations themselves, eligibility, cross-aging, concentration, reserves, and availability, run as deterministic rules configured to your credit agreement. The same inputs and the same rules produce the same number every time, and the AI never touches a calculated value.

The output is a signed certificate or facility report where every line traces to source: the file, the row, the rule version, and the run that produced it. Preparer and approver roles are separated, and the audit trail persists. None of this replaces lender review, and it is not meant to. The goal is narrower: that what you submit is right, on time, reproducible, and checkable line by line, so the review is about your business rather than your spreadsheet.