File-Based Data Import (FBDI) is the standard way to bulk-load data into Oracle Fusion Applications. It is reliable, well documented and used on almost every Fusion implementation. It also makes it easy to believe a migration is complete when it is not. A successful import only means the rows passed Oracle's validation. It does not mean the data is right.
This guide explains how to validate data migrated through FBDI, based on our FBDI validation playbook. It is written for Oracle consultants, data migration leads and finance controllers who must sign off opening balances.
How FBDI works, briefly
For each business object Oracle supplies a spreadsheet template. The usual flow is:
- Download the FBDI template for the object from the Oracle documentation for your release.
- Populate the template from the legacy extract.
- Use the template's macro to generate a zipped CSV file.
- Upload the file and run Load Interface File for Import, which loads it into interface tables.
- Run the object's import process to move data from interface tables into the application tables.
- Review the output and error reports, correct the source and reload rejected rows.
Always use templates that match your environment's release. Templates change between releases, and an old template is a common cause of errors. The Oracle Fusion Financials documentation links to the FBDI templates for each release.
The four layers of validation
Validation works in layers. Each catches a different kind of problem.
1. Record counts
For each object and each load, record three numbers: rows in the source extract, rows loaded successfully, rows in error. Source must equal loaded plus errored. If it does not, rows were lost between extract and load, usually through filters or transformation logic.
2. Balance reconciliation
Counts do not prove values. For financial objects, reconcile totals:
| Object | Reconcile against | Typical tolerance |
|---|---|---|
| GL opening balances | Legacy trial balance by account and entity | Zero |
| Open supplier invoices | Legacy AP aging by supplier | Zero |
| Open customer transactions | Legacy AR aging by customer | Zero |
| Fixed assets | Cost, accumulated depreciation and net book value by category | Zero |
| Bank balances | Bank statements at cutover date | Zero |
| Inventory (if in scope) | Quantity and value by item and location | Agreed rounding only |
For finance data the tolerance is almost always zero. If a difference is accepted, record why and who accepted it.
3. Sample checks
Pick 5–10% of records for each object, weighted towards complex cases: multi-currency invoices, suppliers with many sites, assets with adjustments, customers with several bill-to addresses. Compare each field against the source. This catches mapping errors that totals hide, such as wrong payment terms, swapped address lines or the wrong tax registration.
4. Functional checks
Use the migrated data in real transactions. Pay a migrated supplier invoice. Apply a receipt to a migrated customer transaction. Depreciate a migrated asset for one period. If the data cannot be used, it is not correct, whatever the counts say.
Handling errors
FBDI errors fall into a few groups:
- Missing reference data. Suppliers, customers, accounts, business units or lookups that the record refers to do not exist yet. Fix the load order.
- Invalid values. Codes that do not match Fusion setups, such as payment terms or tax classification codes. Fix the mapping.
- Format problems. Dates, decimals and character sets. Fix the extract or template.
- Duplicates. Records already loaded in a previous run. Purge interface data and reload cleanly.
Always fix errors at the source or in the mapping, then reload. Manual fixes in Fusion after the load cannot be repeated for the next mock or for cutover.
Load order matters
Load reference data before the transactions that depend on it. A typical finance sequence:
- Chart of accounts values and hierarchies.
- Suppliers, supplier sites and bank accounts.
- Customers, sites and accounts.
- Fixed asset additions.
- Open Payables invoices.
- Open Receivables transactions.
- GL opening balances, posted after subledgers so control accounts tie.
This follows the setup order in our Fusion Financials implementation steps.
Mock loads and cutover
Plan at least two or three full mock loads before go-live. Treat each one as if it were production: reconcile, record results, and get sign-off. Time the final mock. That timing becomes your cutover plan. Include migration sign-off in the go-live readiness checklist: "data conversion reconciled (counts and balances)".
Validation checklist
- Templates match the environment's release
- Load order documented and followed
- Source, loaded and errored counts recorded for every object
- Source equals loaded plus errored for every object
- Trial balance reconciled by account and entity
- AP and AR agings reconciled by supplier and customer
- Asset cost, depreciation and NBV reconciled by category
- 5–10% sample checked field by field
- Functional checks passed on migrated data
- Errors fixed at source; no manual fixes in Fusion
- Data owner sign-off recorded for each object
- Final mock load timed and cutover plan updated
Keep a migration log
Keep one log for the whole migration, updated after every load. For each object and run it should record the source extract date, template version, counts, reconciliation results, errors found and fixes made, and who signed off. The log shows auditors how opening balances were established. It also makes the next mock load faster, because every fix is written down rather than remembered by one consultant. Store reconciliation working papers with the log, not in personal folders.
Who signs off
Every object needs a named data owner from the business, not the implementation team. The owner reviews the reconciliation and signs to confirm the data is complete and correct. For finance, this is usually the financial controller for balances and the AP and AR managers for their subledgers.
How Egisedge helps
Egisedge Technologies is an Oracle Partner implementing Oracle Fusion Cloud ERP, HCM and SCM, with Oracle Integration Cloud for automated loads through FBDI. Our OIC playbook covers using the ERP adapter to import bulk data with callbacks. Our directors bring 20+ years in Oracle EBS and Fusion and 16+ years in Oracle Finance, SCM and OTM, and we deliver from India with teams covering GCC, UK/Europe, US and Australia/NZ working hours.
Planning a migration to Oracle Fusion, or struggling to make the numbers tie? Email info@egisedge.com or book a demo with our team.
Frequently asked questions
What is FBDI in Oracle Fusion?
File-Based Data Import (FBDI) is Oracle's standard method for bulk-loading data into Fusion Applications. You populate an Oracle-supplied spreadsheet template, generate a zipped CSV file, upload it and run the import process for that object.
How do you validate data loaded through FBDI?
Compare record counts between source, loaded and errored rows; reconcile balances such as the trial balance, open payables, open receivables and asset values; check a sample of records field by field; and get sign-off from the data owner for each object.
What causes most FBDI import errors?
Missing or invalid reference data such as suppliers, accounts, business units or lookups; date and number format problems; and templates that do not match the release of the environment.
How many mock loads are needed before go-live?
Most projects plan at least two or three full mock loads, with the final one run as a timed rehearsal of the cutover. Each mock should be reconciled and signed off as if it were production.
Talk to Egisedge about ERP Financials
Tell us where you are and we'll reply within one working day with next steps.