Oracle Fusion · Financials · Transactional

Oracle Fusion AP Invoice Data Migration

Migrate accounts payable invoices into Oracle Fusion, covering invoice headers, lines, distributions, matching to purchase orders, holds and the open balance position at cutover.

Discuss Your Migration All Migration Objects

Object overview

AP invoice migration is a balance problem disguised as a transaction problem. The purpose is not to reproduce every invoice ever entered — it is to arrive at a payables position that agrees with the general ledger and lets the business pay what it owes. That reframing decides scope: open and partially paid invoices migrate, fully settled history usually does not.

The complication is dependency. An invoice needs its supplier and site, its business unit, its accounting distributions and — where it was matched — its purchase order and receipt. Everything it touches must already exist and be correct.

What data is typically migrated

Scope is agreed in discovery; this is the shape of the object.

Data area	Typical information
Invoice header	Invoice number, supplier, site, date, currency, amount, type, terms
Lines	Item and freight lines, quantities, unit prices, tax lines
Distributions	Accounting distributions with the full code combination
Matching	PO and receipt references where the invoice was matched
Holds	Active holds that must survive the move
Payment status	Amount paid, amount remaining, scheduled payments
Attachments	Scanned invoice images where in scope

Object relationships

Dependency drives load sequence: a child cannot exist before its parent.

Supplier + Supplier Site

└─ AP Invoice header

└─ Invoice line

└─ Distribution → GL code combination

└─ PO / receipt match

└─ Hold

└─ Scheduled payment

Object migration flow

Source AP Invoices→DataMove→Map & transform→Validate→Oracle Fusion AP Invoices→DataVault reconciliation→Sign-off

Before you migrate this object

Confirm each of these before the first migration cycle.

□Chart of accounts is frozen and code combinations are mapped

□Suppliers and sites have loaded and reconciled

□Accounting periods are open for the cutover dates

□Open-versus-history scope is agreed and signed off by finance

□Payment terms crosswalk is approved

□Matched-invoice policy is agreed (migrate POs, or load unmatched)

□The AP-to-GL reconciliation method is agreed before the first cycle

Common source systems

Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

Oracle EBS Production-provenSAP ECC Production-provenOracle JD Edwards SupportedMicrosoft Dynamics 365 SupportedPeopleSoft Supported

Source-to-target mapping examples

Object-level equivalence. Field-level mapping is produced per engagement.

Source system	Source entity	Target object
Oracle EBS	AP Invoices + Distributions	Fusion AP Invoice + Distributions
SAP ECC	Vendor open items (BSIK) + document (BKPF/BSEG)	Fusion AP Invoice
JD Edwards	A/P Ledger (F0411)	Fusion AP Invoice

Migration methods for this object

Payables Standard Invoice Import FBDI (header, line, distribution files)

Invoice REST services for corrective loads

Open-balance approach: load remaining amounts rather than full payment history

Extraction considerations

Open items only, in most casesThe practical scope is invoices with a remaining balance at cutover, plus enough recently closed history for operational reference. Fully settled history is archived.

Partially paid invoicesThese need the remaining amount, not the original amount. Getting this wrong overstates payables on day one and is difficult to unwind.

Matched invoicesIf the purchase order and receipt are not also migrating, matched invoices are loaded unmatched with the PO reference retained as a text attribute rather than a live link.

Prepayments and credit memosThese carry sign and application relationships that are easy to lose. They are extracted and validated as their own categories.

Tax linesRecoverable and non-recoverable tax must land on the right distributions or the tax position will not reconcile.

Transformation rules

Original amount to remaining amountOpen-balance migration loads what is still owed. The transformation derives remaining amount from original less applied payments and credits.

Code combination mappingEvery distribution's account is mapped from the source chart of accounts to the Fusion code combination, which is where a chart-of-accounts redesign lands on this object.

Supplier and site resolutionEach invoice resolves to a migrated supplier and the correct site for its business unit, using the cross-reference built during supplier migration.

Payment terms and due datesTerms are crosswalked and scheduled payment dates recalculated so ageing is correct at go-live.

Currency and exchange rateForeign currency invoices carry their rate and rate date so revaluation behaves correctly.

Data quality and validation

Supplier and site exist

Every invoice resolves to a loaded supplier site in the right BU.

Distributions balance to the header

Line and distribution totals equal the header amount.

Code combination is valid and enabled

Every account combination exists and is open for posting.

Period is open

The accounting date falls in a period Fusion will accept.

Duplicate invoice check

Supplier plus invoice number plus date, which Fusion also enforces.

Remaining amount is non-negative

Except where the record is a credit memo.

Load sequence and dependencies

What has to exist before this object can load.

1Chart of accounts and open periods
2Suppliers and supplier sites
3Purchase orders and receipts (if matched invoices are in scope)
4AP invoice headers
5Invoice lines
6Distributions
7Holds
8Scheduled payments
9Attachments

Common migration errors

What actually fails on this object, and why.

Supplier site not foundThe invoice references a supplier-BU combination that did not load.

Distributions do not balanceLine or distribution totals disagree with the header amount.

Invalid code combinationThe mapped account does not exist, is disabled, or is not valid for the ledger.

Closed periodThe accounting date falls outside an open Fusion period.

Duplicate invoiceFusion already holds the same supplier, invoice number and date.

Unmapped payment termDue date cannot be derived, so ageing would be wrong.

Tax line mismatchTax amounts do not agree with the calculated tax for the line.

Reconciliation

Counts alone rarely prove this object migrated correctly.

Open payables total: source AP subledger balance vs loaded balance, to the ledger

Invoice count: open invoices in source vs loaded

Ageing buckets compared, not just the total — a correct total with wrong dates is still wrong

By supplier: top suppliers reconciled individually

Currency-by-currency totals for multi-currency estates

Rejected invoices categorised; agreed exclusions (settled history) listed explicitly

Should all historical records be migrated?

Fully settled invoices are the classic archive candidate. They carry statutory retention obligations but no operational purpose in the new ERP, and loading years of them slows every migration cycle and inflates the target. The common pattern is to migrate open and recently closed items, and preserve settled history in a searchable archive that finance and audit can query directly.

Legacy system archival Historical reporting

How Syntra ETL supports this object

DataMove

Extraction, mapping, transformation, validation preparation and target load generation.

Explore DataMove →

DataVault

Preserves source, prepared and target states for reconciliation, lineage and audit evidence.

Explore DataVault →

DataLens

Migration progress, data quality, exceptions and readiness across cycles.

Explore DataLens →

Relevant migration routes

Source-specific guidance for moving this object.

SAP ECC→Oracle Fusion

Successfully delivered projects involving this object

Published case studies whose scope included ap invoices.

InfiniumSMS+5 more→Oracle Autonomous Database (ATP)Catholic Healthcare TrustHealthcare · USA

5 Legacy systems retired
~8 TB Data archived
~150K Attachments

All five legacy systems decommissioned; the consolidated archive is live in production.SUCCESSFULLY DECOMMISSIONEDView Project →Oracle EBS→Oracle FusionMajor Saudi Government OrganizationGovernment · Middle East

18 Business units
1M+ Inventory items
5× Faster than manual loading

Loaded roughly five times faster than manual loading, with every object reconciled.DELIVERED WITH GLOBAL SIView Project →

Frequently asked questions

Should all AP invoice history be migrated to Oracle Fusion?

Rarely. The usual scope is open and partially paid invoices plus a short tail of recently closed items for operational reference. Settled history carries retention obligations but no operational value in the new ERP, so it is normally archived instead.

How are partially paid invoices handled?

They migrate at their remaining amount rather than their original amount. Loading the original overstates payables at go-live, and correcting it afterwards means manual adjustments that distort the AP-to-GL reconciliation.

What happens to invoices matched to purchase orders?

If the purchase orders are also in scope they migrate first and matching is preserved. If not, the invoice loads unmatched with the PO number retained as a reference attribute.

How is AP migration reconciled to the general ledger?

The loaded payables balance must agree with the AP control account in the ledger, by business unit and by currency. Ageing buckets are reconciled too, because a correct total with incorrect due dates still produces wrong payment behaviour.

Can invoice images be migrated?

Yes, as a separate workstream. Attachments sit in a content store rather than in the invoice tables, and scope is agreed explicitly because volume is usually large.

Planning a similar data migration?

Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.

Discuss Your Migration Explore Migration Routes