FREE RESOURCE

ERP receivables data map for borrowing base certificates

Every borrowing base error we see traces back to a field mapping: a due date computed from the wrong terms, a credit memo exported with the wrong sign, a child account breaking concentration math. This map shows where each certificate input lives in NetSuite and SAP, and the five breakages to test before you trust the extract.

Who this is for

Controllers setting up lender reporting from a new ERP
AR managers who own the monthly data extract
Analysts building the borrowing base workbook
Anyone migrating ERPs mid-facility

What it includes

A field-by-field map from certificate inputs to NetSuite and SAP fields
The customer master fields that drive eligibility and concentration
The transaction types that must survive the extract
The five most common mapping breakages with the symptom that reveals each one

The core invoice fields

These seven fields are the minimum for computing aging, eligibility, and the roll-forward. Field names below are the common defaults; customized instances move things, so verify against your own schema.

CERTIFICATE INPUTS MAPPED TO NETSUITE AND SAP
Certificate input	Typical NetSuite field	Typical SAP field	Notes
Invoice number	tranId on the invoice record	BELNR (accounting document) or VBELN (billing document)	Pick one system of record. SAP billing and accounting document numbers differ, and mixing them creates phantom duplicates
Obligor	entity (customer internal ID)	KUNNR on the open item	Extract the ID, not just the display name. Names change, IDs do not
Invoice date	tranDate	BLDAT (document date)	If your agreement ages from invoice date, this field drives eligibility. SAP posting date BUDAT is not the invoice date
Due date	dueDate	Computed: ZFBDT baseline date plus ZBD1T terms days	SAP stores the baseline and terms separately. Compute the due date in the extract, do not assume a field holds it
Payment terms	terms	ZTERM (terms of payment key)	Needed to test extended terms eligibility, for example excluding invoices with terms over 90 days
Open amount	amountRemaining (foreignAmountUnpaid for FX)	WRBTR in document currency, DMBTR in local currency, from open items (BSID)	Use the open amount, not the original amount. Partially paid invoices count at their remaining balance
Currency	currency on the transaction	WAERS	Carry the transaction currency and the rate used to translate, so the certificate's FX note is reproducible

Customer and obligor master fields

Eligibility and concentration are tested at the obligor level, so the customer master matters as much as the invoice file.

MASTER DATA FIELDS THAT DRIVE ELIGIBILITY
Purpose	Typical NetSuite field	Typical SAP field	Notes
Obligor group (parent)	parent on the customer record	Customer hierarchy (KNVH) or trading partner VBUND	Concentration must roll subsidiaries up to the ultimate parent, or one obligor looks like five small ones
Country	billCountry on the billing address	LAND1 on the customer master	Drives the foreign receivables test. Bill-to country and ship-to country can differ, and the agreement usually cares about the obligor's jurisdiction
Intercompany flag	representing subsidiary link on the customer	Trading partner VBUND populated, or a dedicated account group	Related-party receivables are ineligible under most agreements, so this flag must be reliable
Government obligor	custom field or customer category	Account group or industry key BRSCH	Government receivables are often excluded or capped; most ERPs need a deliberate flag for this

Transaction types that matter

An extract that only pulls invoices overstates the base. These types must come through with the correct sign and date.

Credit memos: negative open amounts, aged on the basis your agreement specifies; they drive the dilution ratio and reserve
Unapplied and on-account cash: payments not matched to invoices, which most agreements deduct until applied
Write-offs: needed for the roll-forward and, in securitizations, the default ratio; capture the write-off date, not just the reversal
Disputed invoices: however your ERP flags them, dispute codes or hold flags must survive the extract so the ineligible test can see them
Journal entries hitting AR: manual JEs to the control account are the classic reason the aging and the GL disagree

The five most common mapping breakages

Due date computed from the wrong baseline. Symptom: past due ineligibles jump or collapse after an ERP change while actual payment behavior is unchanged. Test 20 invoices by hand against their terms
Credit memos exported as positive amounts. Symptom: gross AR exceeds the GL control account and the roll-forward will not tie; dilution looks near zero for a business that issues memos every week
Open amounts left in transaction currency. Symptom: the aging total drifts from the GL by exactly the FX revaluation amount, and the gap moves with exchange rates month to month
Obligor mapped at the child or ship-to level. Symptom: no customer ever trips the concentration limit, even though you know one buyer is 15 percent of revenue
Unapplied cash dropped from the extract. Symptom: the aging total is higher than the subledger balance, and eligible AR is overstated by the unapplied amount; the lender's field exam will find this one

Get the working data map spreadsheet

Olycor is in early access. Sign up and we will send you this data map as a working spreadsheet with columns for your own ERP's field names and the three monthly break checks built in, and show you how the platform interprets raw ERP extracts into certificate-ready data.

Get early access

What this resource does not replace

Your credit agreement's definitions of the inputs these fields feed
Legal or accounting advice on your facility
Your lender's review of the resulting certificate

Frequently asked questions

We run an ERP other than NetSuite or SAP. Does this map still help?+

Yes. The certificate inputs in the left column are the same for every system. Dynamics, Oracle Fusion, Intacct, and QuickBooks all hold equivalents of these fields under different names. Use the notes column as the test list: sign conventions, due date computation, and parent rollup break the same way everywhere.

Should the extract come from the aging report or from raw open items?+

Raw open items. Aging reports bake in bucket logic that may not match your credit agreement, and they often exclude unapplied cash or credit memos depending on settings. Pull open items with the fields above and compute aging yourself, on the basis the agreement defines.

How do we keep the mapping from silently breaking?+

Add three checks to every cycle: extract total equals the GL control account, credit memo total is negative and roughly consistent with recent months, and the count of rows missing any core field is zero. A mapping break almost always trips one of those three before it distorts the certificate.