The Nightly Feed That Turned 4,800 Invoices into 11,600
Orion Forge Components runs Receivables in the Orion US BU on the US Primary Ledger. Its legacy ERP sends one flat file per night through the AutoInvoice import; a typical night is 4,800 source documents worth 6.2 million USD. Each document carries one to four item lines plus a tax line and a freight line. After go-live the nightly run created 11,600 transactions. In the same run, 640 lines were rejected with 'the GL date is not in an open period' because the legacy extract sends original document dates from 2019 to 2021 for migrated open items, and 212 lines were rejected with 'ship-to site is not valid for this business unit' for 46 customers whose addresses exist in the customer registry but were never associated with Orion US BU. Finance wants migrated open items to appear in the current period while keeping the original document dates on customer statements and aging.
1. Explain why a 4,800-document feed produced 11,600 transactions, and recommend both the forward fix and the treatment of the transactions already created.
Read the worked answer
Diagnosis: grouping, not duplication. AutoInvoice decides how many transactions to build by applying the grouping rule on the transaction source. With the rule set to NONE, every interface line becomes its own transaction, so 4,800 multi-line documents shred into roughly 11,600 single-line invoices. No data is corrupted; the transactions are simply fragmented.
Forward fix: define a grouping rule whose attributes require the customer and the invoice identifier supplied by the extract to match before lines are merged, attach it to the LEGACY_INV source, purge the interface tables, and re-import a 50-document control batch. Verify document count equals transaction count before releasing the full feed.
Backward fix: the 11,600 transactions are complete, so they cannot be deleted - deletion is only available for incomplete transactions. For those with no payments and no accounting, void them; voiding zeroes the balance and reverses the accounting. Where accounting already exists or a payment was applied, raise credit memos rather than attempting deletion. Critically, never re-import the same file to 'correct' it: that doubles receivables and revenue, and the error will surface only in the AR-to-GL reconciliation weeks later.
2. How should the 640 GL date rejections be resolved so that migrated open items land in the current period without losing the original document dates?
Read the worked answer
The GL date is what selects the accounting period, and it is derived from the transaction source's accounting date source or supplied explicitly on the interface line. A 2019 document date cannot post to a 2019 AR period that is closed and should stay closed, so the answer is to separate document date from accounting date rather than to reopen old periods.
Recommended approach:
- Keep the legacy document date in the transaction date and the original due date on the interface line - aging, dunning and statements use these fields, not the GL date.
- Set the transaction source (or the interface batch) so the accounting date resolves to the current open period, or populate a valid accounting date explicitly in the extract.
- Load and post the migrated items into a clearly labelled current-period batch so the migration is visible and reconcilable.
Consequences to flag to the controller: current-period revenue and receivable balances will include historical documents, so the AR-to-GL reconciliation and any period-over-period reporting need a migration note. Also confirm whether tax on those items was already reported in the legacy system; if so, migrate the tax as a non-taxable line or adjust the tax setup to avoid double reporting.
3. What is the correct remediation for the 212 site rejections, and what risk should be checked before re-importing those lines?
Read the worked answer
A customer account and its addresses are shared across business units, but an address is only usable in a business unit once it has been associated with that business unit. That association is what is missing for the 46 customers, so the transactions cannot resolve a valid ship-to for Orion US BU.
Remediation:
- Use a bulk load (customer import or the spreadsheet/REST interface) to add Orion US BU to the affected site records; do not hand-edit 46 customers if more lines are coming.
- Confirm each account is active, not on credit hold, and that the site use being referenced (bill-to vs ship-to) exists.
- Re-import only the rejected lines, not the whole batch, after purging the failed rows.
Risk to check before re-importing: the failed lines may already have been corrected manually and re-keyed, in which case re-importing the interface rows creates genuine duplicates. Reconcile the rejected line list against transactions created in the period before you resubmit. Also verify that the customer names on the legacy extract match the registry exactly; a near-match that was auto-created as a new account during the first run must be merged or the balance will split across two accounts.