The data your lender needs already sits in your ERP. What breaks every month is the path from that export to a signed certificate: field mapping, obligor cleanup, credit memo handling, and a reconciliation nobody has time to document.
The ERP to certificate workflow takes the AR aging or open invoice export from your ERP, maps its fields to certificate inputs, normalizes dates, amounts, currencies, and obligor names, applies the credit agreement's eligibility rules deterministically, reconciles the result to the general ledger, and produces a signed borrowing base certificate traceable to source rows.
In most finance teams the answer is one analyst, one spreadsheet, and two to three days a month. The analyst exports aging detail, fixes the columns, deletes credit memos or forgets to, pivots by customer, applies the eligibility tests from memory, and pastes totals into the lender's template. Every step is a chance to misstate the certificate, and none of it is documented well enough to survive a field exam without a long afternoon of explanation.
Olycor replaces those steps with a pipeline. The export is mapped once, the mapping is remembered, normalization runs the same way every period, and the eligibility, reserve, and concentration math runs as deterministic rules configured to your credit agreement. The analyst's job shifts from rebuilding the calculation to reviewing exceptions and approving the output.
No system migration, no six month connector project. The first input is the export your team pulls today, and messy formats are a supported case, not a failure mode.
Saved searches and AR aging detail exports. TranDate, DueDate, Entity, FxAmount, and Amount Remaining map directly to certificate inputs.
FBL5N line items and aging reports. Document date, baseline date plus terms, customer number, and document currency amounts.
Customer aging and open transaction exports, including the invoice-level detail behind each aging bucket.
A/R detail exports from the F03B11 ledger, with due date, open amount, and payor mapping handled per instance.
Customer invoice and aging reports from Workday Financial Management, mapped like any other structured source.
Subsidiary on QuickBooks, a factored book in a PDF statement, a controller emailing a spreadsheet at 6pm on close day. All valid inputs.
Every ERP names the same eight facts differently. The mapping below is where most spreadsheet processes quietly go wrong, and it is the first thing Olycor locks down. Each mapping decision is recorded, versioned, and reused next period.
| Source field (varies by ERP) | Certificate input | Why it matters |
|---|---|---|
| TranDate / Document Date / Invoice Dt | Invoice date | Starts the aging clock for the 90 day past invoice test |
| DueDate / Net Due Date / baseline + terms | Due date | Starts the clock for past due eligibility tests |
| Entity / Customer / KUNNR / Payor | Obligor | Matched into an obligor group for concentration limits |
| FxAmount / Amount in Doc Currency | Currency amount | Converted at the certificate FX rate where the facility allows it |
| Amount Remaining / Open Amount | Open balance | The amount actually tested for eligibility, not the original face value |
| Currency / WAERS / Curr Code | Currency code | Drives FX conversion and foreign obligor eligibility |
| Memo / dispute flag / hold code | Dispute status | Feeds the disputed invoice exclusion |
| Transaction Type / Doc Type | Invoice vs credit memo | Credit memos net against the pool and feed dilution tracking |
One example of the stakes: mapping TranDate where the aging tests expect a due date shifts every invoice's age by the payment terms. On net 60 terms, that single mapping error can move an entire aging bucket and overstate eligible receivables by millions before any rule runs.
The classic breakages are boring and expensive. Due dates that are not stored anywhere, only derivable from invoice date plus terms, and the terms field says "2/10 net 30" in one subsidiary and "N30" in another. Amounts exported in transaction currency next to a column in functional currency, with no header saying which is which. A date column that reads 03/04/2026 and means March in the US file and April in the UK file.
Then the customer problem: the same obligor spelled three ways. "Meridian Components", "Meridian Components LLC", and "MERIDIAN COMP" are one counterparty for concentration limits and cross-aging, but a spreadsheet treats them as three and understates the exposure. Olycor matches names into obligor groups and asks a human to confirm the matches it is not sure about.
Credit memos are the third trap. Some ERPs export them as negative invoices, some as a separate document type, some netted invisibly into open balances. Each treatment changes both the pool total and the dilution history the reserve is built on. Olycor classifies them explicitly, so a credit memo is never silently counted as collateral.
Two checks run before anything is signed. The first is internal: mapped invoice detail is totaled against the source file's control totals, by count and by amount, so a dropped row or a double-counted credit memo is caught at ingestion, not by the lender. If the export said $38,400,000 of open AR across 4,212 invoices, the mapped pool has to say the same thing.
The second is external: gross AR on the certificate is compared to the AR control account in your general ledger for the same date. Timing differences are real, unapplied cash and unposted invoices exist, so the variance is itemized rather than forced to zero. A certificate that shows a $140,000 reconciling item with an explanation is credible. A certificate that silently disagrees with the GL by $140,000 is a field exam finding.
Most certificate errors are born at the mapping step, long before any eligibility rule runs. These are the breaks Olycor checks for on every ingestion.
| Where it breaks | What it looks like | The consequence |
|---|---|---|
| Date field mapping | TranDate mapped where the aging tests expect a due date | On net 60 terms every invoice's age shifts by 60 days, and whole aging buckets move before any rule runs |
| Credit memo document types | Credit memos exported as positive rows with no document type column mapped | $380,000 of credits are counted as collateral, and the dilution history feeding the reserve is missing |
| Currency columns | Document currency exported next to functional currency with no header saying which is which | A EUR 1,000,000 invoice enters the base as $1,000,000, and the error resizes with every rate move |
| Duplicate rows | An invoice appears in both the parent's export and the subsidiary's | $250,000 is counted twice, and only a control total check against each source file catches it |
| Custom fields ignored | A custbody dispute flag or SAP hold code never wired into the eligibility rules | Disputed invoices stay in eligible AR until a field examiner samples one |
| Terms parsing | Payment terms stored as 2/10 net 30 in one entity and N30 in another | Derived due dates disagree across entities, and the same invoice ages differently depending on where it was booked |
Because the mapping decisions are on the record, a credit analyst or field examiner can check the path from ERP export to certificate without reconstructing it. None of this replaces lender review; it gives the review something solid to test.
The certificate shows which source column fed each input, so a reviewer can see that DueDate, not TranDate, drives the aging.
Each value opens to the invoices behind it, and each invoice links to the export it arrived in, down to the row.
Mapped detail matches the source file by invoice count and by amount, so nothing was dropped or duplicated between ERP and certificate.
An ineligible invoice shows the test that fired and the limit it failed, taken from the credit agreement rather than a spreadsheet convention.
The roll-forward reconciles to the prior period, and gross AR is compared to the GL control account with variances itemized.
Field mappings and eligibility rules are versioned against the credit agreement, so any historical certificate can be reproduced exactly.
The end of the pipeline is a certificate in the format your credit agreement specifies, with the eligibility walk from gross AR to availability, prepared by one person and approved by another, then signed by an officer. Every line on it opens to the invoices behind it, and every invoice links to the file and row it came from. That lineage is described in detail in source-level auditability.
None of this replaces lender review. The credit team still checks the certificate, field examiners still test it, and your agreement still governs. What changes is the quality of the conversation: questions get answered from lineage in minutes, not reconstructed from a spreadsheet in days.
Or browse the full receivables finance glossary and the eligibility rule library.
Last updated July 9, 2026. Olycor does not provide legal, tax, accounting, or credit advice. Facility terms, eligibility criteria, and reserve mechanics vary by credit agreement; your agreement governs.
Olycor is onboarding borrowers who want the path from export to signed certificate to take minutes, with every step on the record.