How to turn ERP receivables data into a certificate your bank will accept

Your ERP knows everything about your receivables. Every invoice, every credit memo, every payment application, timestamped and stored. And yet every month, someone on your team exports it all to a spreadsheet, spends two days reshaping it, and produces a borrowing base certificate that the bank then questions. The gap is not missing data. It is that ERP data and certificate math speak different languages, and the translation layer is usually one overworked analyst and a workbook with 40 tabs.

Start with the data map, not the template

Most teams start from the lender's certificate template and work backwards, hunting through exports for numbers that fit each line. It is faster to go the other way: define once which ERP fields feed which certificate inputs, then let every month flow through the same map. Here is what that map typically looks like for NetSuite and SAP style systems.

None of these mappings is exotic. The problem is that they drift. A new subsidiary starts invoicing, a customer gets re-keyed under a second ID, someone adds a custom transaction type for rebates. If the map is not maintained as deliberately as the chart of accounts, the certificate slowly disconnects from reality.

The four breakages that ruin certificates

We have watched teams lose a week to each of these. They account for the large majority of certificate disputes we see between borrowers and lenders.

• Invoice date versus due date. Your agreement ages receivables from one of them, commonly 90 days from invoice date or 60 days past due. If your ERP export ages from the other, every bucket is wrong. On a $14.6 million book with 60 day terms, the difference can move $1 million or more between eligible and ineligible.
• Customer names spelled differently. Acme Corp, ACME Corporation, and Acme Corp. (Ohio) are one obligor to your credit agreement and three customers to your ERP. Concentration gets understated, and cross-aging tests miss balances they should catch.
• Credit memos posted as negative invoices. If a $75,000 credit memo sits in the export as a negative line, naive aging logic can net it against current invoices while the disputed original sits untouched in the over 90 bucket. Dilution reporting quietly breaks.
• Multi-currency. A EUR 500,000 invoice is not $500,000. Certificates need a consistent conversion policy, usually the rate on the certificate date, and many agreements make some or all foreign receivables ineligible regardless.

From export to certificate, step by step

Whether you run this in software or by hand, the sequence is the same. The order matters: normalize before you test, test before you calculate.

• Export open AR at invoice level as of the cutoff: customer, invoice number, invoice date, due date, original and open amounts, currency, transaction type.
• Normalize identities: collapse duplicate customer records and roll subsidiaries up to the parent obligor your agreement measures against.
• Classify transactions: separate true invoices from credit memos, unapplied cash, finance charges, and intercompany balances.
• Convert currency to the facility currency at the certificate date rate, and flag foreign obligors for the eligibility test.
• Run eligibility tests in the order your agreement defines them: aging, cross-aging, disputes, contras, obligor type, then concentration on what remains.
• Compute reserves, apply the advance rate, and build the roll-forward tying this certificate to the last one.
• Trace check: pick three ineligible totals at random and confirm each resolves to specific invoices before anyone signs.

Prove the export ties to the general ledger

There is a step most teams skip, and it is the one that decides whether your bank trusts the whole package: reconcile the invoice level export to the AR control account before you build anything on top of it. If the export sums to $14,600,000 and the general ledger says $14,830,000, you have a $230,000 gap, and it has a finite set of causes. Unapplied cash sitting in a clearing account. Invoices posted after the export ran. A subsidiary whose transactions did not make the saved search. A journal entry booked straight to the control account that never touched an invoice.

Find the gap now and it is a footnote. Let the lender find it and it is a finding. Most agreements require the certificate to tie to the books, and field examiners test exactly this reconciliation on day one of an exam. The teams that handle this well keep a standing tie-out schedule: export total, plus or minus each named reconciling item, equals the GL balance, signed off before the certificate math starts. It takes twenty minutes when the map is clean and saves days when something drifts.

Where AI helps, and where it has to stop

Steps one through four are interpretation problems. Which column is the open amount, is this row a rebate or a credit memo, are these three customer records the same company. That is pattern recognition over messy inputs, and modern AI is genuinely good at it, better than a rules list that breaks the first time a column header changes.

Steps five through seven are a different animal. Eligibility, concentration, reserves, and the roll-forward are contract math. The output decides how much money moves, so it cannot be probabilistic. It has to be deterministic: same data, same rules, same answer, every single run, with each number traceable to its source invoices. This split is the design principle behind Olycor. AI reads whatever your ERP produces, then hands clean records to a rules engine that computes the certificate the same way a well-rested analyst with perfect memory would, and the result goes out signed.

Let AI read the data. Never let it do the math your bank lends against.

One last habit worth stealing: keep the raw export you built each certificate from. When your lender asks in October why March ineligibles jumped, the team that archived source-level data answers in an hour. The team that did not gets to reconstruct history from memory, in front of a field examiner.