The Three Fields a Machine Misreads on a Borrowing Base Certificate

Last updated: September 23, 2026

By Khurram Tehseen, FSA, Founder and Principal at Operating Alpha

The three fields a machine misreads on a borrowing base certificate are the sign on a credit balance, the account debtor’s name, and the invoice date behind each aging bucket. Each can be read correctly off the page and still produce the wrong availability. Each needs an uncertainty tag that says why.

Page 22 of the aging had a line that read 61,480.00- in the current column.

The minus sign sat after the number. Plenty of older ERP report writers still print credits that way. The extraction returned 61,480.00, and every other digit on all 31 pages came back right.

It was a credit memo. Dropping one character turned a $61,480 reduction into a $61,480 receivable, so the aging total moved by twice that, and availability at an 85% advance rate moved by $104,516. In the borrower’s favor, naturally.

Every digit was correct.

I have watched machines read borrowing base certificates at enough funds now to see where they miss. The misses cluster in three fields. Usually the same three. In each one the page gets read correctly and the answer still comes out wrong, because the meaning of the field lives somewhere the page doesn’t show. The general method, six steps from ingest to ground truth, is laid out in my write-up of the document-to-decision build. The staffed version of that build is KORE1’s document-to-decision service. This piece stays on one document and the tags its three worst fields need.

Some context on the venue. KORE1 publishes this, and its data engineer recruiting practice places the people who build pipelines like the one below. I’m a guest on this site, and nothing in this piece requires buying a product.

What a Borrowing Base Certificate Reports, and What It Leaves Out

A borrowing base certificate is the form an asset-based borrower signs, weekly or monthly, telling its lender how much it can draw. It starts from gross receivables and inventory, takes out the ineligibles, applies the advance rates and reserves, and subtracts loans and letters of credit already outstanding. The agings behind it are the evidence.

The certificate is a summary, twenty-odd lines of it. Opening receivables carried from the last certificate, new sales, collections, and credits, then a block of ineligibles every collateral analyst knows by name, including past due credits, contra accounts, interco and related, debtor limits, and the taint factor that handles cross-aging. Those rules are the arithmetic layer. what a borrowing base verification layer actually tests is whether the figures feeding them came from anywhere except the borrower.

A machine reads those lines well. It also learns almost nothing from them, because every number on the certificate is the borrower’s own arithmetic, and a pipeline that confirms the borrower can add has confirmed something you already knew.

The lender redoes the math. From the aging, line by line. That’s where the three fields live.

Field One: The Sign on a Credit Balance

Credits reach an aging in at least five formats, sometimes three of them in one file.

• (61,480.00), the accountant’s parentheses.
• 61,480.00- with the minus trailing, common on reports from older ERP systems and anything that went through an AS/400 at some point in its life.
• -61,480.00. The easy one.
• 61,480.00 CR, usually from a system that also prints DR on the debits, except on the pages where it doesn’t.
• A number formatted in red in Excel with no sign at all. It stays negative right up until somebody prints it on a black-and-white printer or scans it in grayscale, and after that the page carries nothing for a machine or a person to read.

The first one has been measured. Ethan Bradley and his co-authors at Queen’s University Belfast asked GPT-4V 100 questions about 50 real financial tables filed with Companies House, and published the results in the SynFinTabs paper in December 2024. The model got 24 wrong. Twenty-two of those were the right number with its parentheses missing. Two characters. One added instruction telling the model to report parentheses and negation signs lifted accuracy from 76% to 94%.

A prompt fixes most parentheses. It cannot recover a sign that only ever existed as a color. Grayscale keeps nothing. Trailing minus signs still get read as a dash, a smudge, or a stray mark from the next column. Those are silent errors. I count them in their own column when I score AI extraction on credit agreements.

Position decides which way the error runs. Lose the sign on a credit in the current column and eligible receivables go up by twice the credit. Here is page 22 carried through the certificate, with ineligibles held at the borrower’s reported $611,300.

In the over-90 column it runs the other way. Sneakier. A credit sitting in past due shrinks the past-due total, and that’s why most certificates carry a past due credits line to add it back. Lose the sign there and the pipeline overstates the ineligible instead. The certificate looks more conservative than it is, and the credit memo drops out of your dilution numbers entirely.

Credits are where dilution lives. The asset-based lending booklet in the OCC’s Comptroller’s Handbook puts typical dilution at 5% of receivables or less and tells field auditors to review and test credit memos, because rising dilution tends to show up before the trouble does. A borrower under pressure has every reason to issue credit memos late. A pipeline that drops the sign on the ones that do get issued is doing the borrower’s editing for free.

The check costs one subtraction. Sum each column and compare it to the total the report printed. If the sum misses by exactly twice one value in that column, you have found your sign, and the tag can say which line. Then tie the aging total to gross receivables on the certificate, and tie this month’s opening receivables to last month’s closing line. Three tie-outs. All arithmetic.

Field Two: The Account Debtor’s Name

The UCC defines an account debtor as a person obligated on an account. On an aging, that person is a string of text somebody typed into a customer master, possibly in 2011, possibly in a hurry.

Here is one customer from one month’s aging. Call it Northfield Supply. It appears as NORTHFIELD SUPPLY CO., again as Northfield Supply Co., once as Northfield Supply #14, and once, my favorite, as NORTHFIELD SUPPLY DO NOT USE.

A machine reads all four perfectly. Then it counts four customers. Three of your eligibility rules stop working at that moment. Nobody gets an error.

Concentration goes first. The OCC booklet suggests limiting concentrated accounts to 10% to 20% of the receivables borrowing base, and plenty of credit agreements set the debtor limit at 20% or 25%. Northfield at 26% of the aging, split four ways, becomes four debtors at about 6.5% each. Nothing trips.

Cross-aging goes with it. Most agreements make all of a customer’s receivables ineligible once enough of them are past due. That’s the taint factor on the certificate, and it only fires if the pipeline knows the old invoices on NORTHFIELD SUPPLY CO. and the current ones on Northfield Supply Co. belong to the same company.

Then the quiet ones. An affiliate never labels itself. It shows up as an ordinary name that happens to share an address, a phone number, or an officer with the borrower, and the OCC flags affiliate receivables as raising the potential for fraud, particularly under financial stress. A contra account shows up on the borrower’s payables ledger under a slightly different spelling. Which is, in my experience, how contra accounts are usually spelled.

This gets fixed a step before extraction, with one canonical record per account debtor and every spelling that has ever appeared on any aging mapped to it once and kept. That’s the same data foundation I build everywhere else, pointed at customers instead of borrowers. The borrower version, and why three systems report three exposures for one borrower, has its own write-up. Colin Boothe’s piece on resolving duplicate records with AI covers the matching side.

Matching is dull. It also pays back more than any model I’ve tuned. At a specialty finance investor, I built person-matching that reconciled hundreds of thousands of individuals and policies across eleven data domains, and data preparation time fell 84%, from weeks to days. Debtor names on agings are the same problem with fewer rows and more consequences per row.

One tag here matters more than the rest. A debtor appearing for the first time with a large current balance is what a fictitious invoice looks like on paper, and it’s also what a real new customer looks like. The tag can’t tell those apart. A person can.

Field Three: The Invoice Date Behind the Bucket

An aging bucket is arithmetic on a date. Get the date wrong and the arithmetic is flawless and useless. That gap between a clean field score and a wrong answer is why OCR projects stall.

Format is the obvious failure. A date printed 04/03/2026 is April 3 to a borrower’s U.S. entity and March 4 to its U.K. subsidiary, and I have seen both on one consolidated aging. A model will pick one reading. Unless you’ve asked it to say so, it won’t mention that it picked.

Spreadsheets have been doing this to dates for a long time, and geneticists have the paperwork. A 2016 study in Genome Biology found that roughly one-fifth of genomics papers with supplementary Excel gene lists contained gene names Excel had silently turned into dates, SEPT2 becoming 2-Sep. Those went through peer review. Your borrower’s aging went through a controller on the fourth business day.

Basis is the quieter failure. Some agings run from invoice date and some from due date, and the header says which in small type at the top of the first page, when it says at all, and it rarely repeats on page two. A common eligibility cutoff is 90 days from invoice or 60 days past due, whichever comes first. On net-60 terms, an invoice sitting 61 to 90 days past due is between 121 and 150 days old. Read that header as days from invoice and the same invoice passes.

Then there’s the date that’s printed correctly and is still wrong.

Re-aging. The OCC lists re-aged receivables among the ineligibles, and re-aging leaves no trace on a single month’s aging. Say invoice 40117 for $38,250 sat in the 61-to-90-day bucket in July. In August the same $38,250 appears against the same debtor as invoice 40117R, dated August 6, in current. Every field on the August page is legible and correct, and the pattern only exists across the two pages together.

A machine that reads each month’s aging as a fresh document can’t see it. One that carries an invoice ledger from month to month can, with a rule a first-year analyst could write. Invoices age. An invoice, or a debtor-and-amount pair, doesn’t get younger.

An Uncertainty Tag Should Carry Its Reason

Under the document-to-decision approach, every field leaves the pipeline trusted, needing review, or unreadable. On this document, that’s thin. A reviewer handed “needs review” on a $61,480 line opens the PDF and starts over. A reviewer handed “sign inferred, column misses its printed total by exactly twice this value” checks one line and moves on. Thirty seconds.

Write the reason codes before the first certificate runs. The analyst who reviews certificates today should write them. They already know which borrower’s system prints the trailing minus and which one still has the 2011 customer master. That knowledge is still done by hand. One person is the database.

Old Frauds, Same Three Fields

The borrowing base review is a fraud control disguised as data entry. The three fields are the reason I keep saying it.

Fraud is a frequent cause of loss in asset-based lending, the OCC booklet says, and its list of what a fraudulent borrower does reads like a tour of the aging. Falsified sales and collection documents. The same receivables pledged to more than one bank. Diverted cash, misrepresented purchase orders, and overstated inventory. Now hold the three fields up to it. Invented sales arrive as new debtors, or as old invoices that got younger. Hidden dilution arrives as credits, or as credits missing their sign. Related-party sales arrive as debtor names that share an address with the borrower. Same three fields.

A 2016 case in the Southern District of New York is the plain version. A beauty products distributor’s chief executive inflated sales and receivables on the borrowing base certificates sent to two banks, and when the company defaulted in 2014, the outstanding balance was more than $4.8 million. The chief financial officer, the sales manager, and the outside accountant pleaded guilty as well. Four guilty pleas in all. The officer’s certification at the bottom of the form is a control right up until the officer is the problem.

Some of it never reaches your file. A double-pledged receivable looks perfect on your aging. It also looks perfect on the other lender’s. You will never see that one. Lien searches and field exams exist for it.

People catch fraud. What the tags decide is which forty lines out of four thousand those people read this month, and what each line is suspected of. The alternative is reading all four thousand. Few do. The full cost of manual collateral review runs higher than most funds book.

Who Builds the Ledger and Who Clears the Queue

Two seats. The collateral analyst clears the tags and owns the reason codes, for the reasons above, and at a fund with a handful of ABL borrowers, that is usually the same person who already reads every certificate by hand. When the queue outgrows the people reviewing it, a contract credit analyst or a hire through risk analyst staffing covers the extra seat faster than a new requisition usually does.

The second seat builds the debtor master and the invoice ledger that carries each aging forward, month over month, with the tie-outs running on arrival. It’s ETL work with a credit accent, and a good candidate reads a taint factor without asking what it means. KORE1 fills that seat through ETL developer staffing, or through data engineering staff augmentation when the build runs a few months and the upkeep afterward is light, which fits a contract placement better than a permanent hire. Of the people KORE1 places, 92% are still with the client twelve months on. On a ledger build that counts, because replacing the engineer halfway through means explaining cross-aging to somebody new.

Sometimes the certificate turns out to be one piece of a month-end close that runs long for other reasons. The scope widens then, and KORE1’s consulting work on private credit operations picks it up. A quick first check is the diagnostic that replays your last close, which sorts a finished month into waiting, hand work and judgment.

Pushback From the Collateral Desk

Can a Model Read the Certificate Totals and Skip the Aging?

It can, and it will learn almost nothing. The totals are the borrower’s own arithmetic, so reading them confirms the borrower can add. The value sits in rebuilding ineligibles from the aging detail, which is exactly where the sign, the debtor name, and the invoice date live.

Does One Line in the Prompt Fix the Sign Problem?

Parentheses, mostly yes. One instruction closed most of the gap in the Belfast study. A sign that only existed as red formatting is gone once the page is scanned in grayscale, though, and trailing minus signs still slip. Keep the column-total check either way.

Our Borrowers Send Native Excel Files Now. Are We Done?

One field of three. Native files keep the sign. They do nothing for four spellings of one customer, and a date column can arrive as text in one borrower’s file and as a serial number in another’s. Ask for the export anyway. It’s a better input than any PDF, and the other two checks still run on it.

What Happens to Availability While a Tag Is Open?

In my default setup, the tagged amount stays out of the borrowing base until a person clears it. That’s a credit policy call. The credit team owns it, in writing. Borrowers learn quickly which formats get held out, and the files tend to get cleaner within a few cycles.

Is This Worth Building for Six ABL Borrowers?

At six borrowers, skip the software. A spreadsheet with the three checks and a debtor list covers it, and an analyst can put one together in about a week. The rules are the asset. Code can come later, when the book is big enough that the spreadsheet becomes the bottleneck.

Where Does Tagging Sit in the Borrowing Base Process?

Between the certificate arriving and the first draw funded against it. Receive the file, extract, run the tie-outs and the three field checks, clear or hold the tags, then update availability. If tagging happens after funding, it’s an audit trail, and a useful one, but it has stopped being a control.

Two Agings, One List

Take one ABL borrower. Put last month’s aging beside this month’s and match every line by invoice number, then by debtor and amount for anything that didn’t match. Mark each invoice that got younger.

That list needs no model, no vendor, and no budget. It’s the plainest fraud check in this piece. It takes an afternoon.

If yours comes back with anything on it, I’d like to see the list. Connect with me on LinkedIn. Building the ledger properly takes an engineer, and you can ask KORE1 about that seat.