Oracle Fusion exposes three primary data load mechanisms. They look similar from a distance and very different up close. File-Based Data Import (FBDI), HCM Data Loader (HDL) and ADF Desktop Integration (ADFDI) all move data into Fusion, but they serve different product families, run in different ways and report errors in different ways. Picking the wrong one usually surfaces later, in a mock conversion that will not reconcile or a hypercare backlog users cannot clear.
Which should you use: FBDI, HDL or ADFDI?
Use FBDI for bulk loads of Fusion ERP and SCM data such as suppliers, customers, invoices, journals and items. Use HDL for Fusion HCM objects such as workers, assignments and salary. Use ADFDI for smaller, interactive work in Excel: entering, reviewing and correcting records, including after go-live. Most programmes need all three.
| FBDI | HDL | ADFDI | |
|---|---|---|---|
| What it loads | Fusion ERP and SCM objects through product-specific templates, for example GL journals, AP and AR transactions, suppliers, customers and items. | Fusion HCM business objects such as Location, Grade, Job, Worker and Salary, across products including Global Human Resources, Absence Management, Compensation and Global Payroll. | Records exposed through integrated Excel workbooks in Fusion, such as the Create Journals workbook, plus ADFdi correction spreadsheets for some import errors. |
| File format | Oracle-provided Excel templates whose macros generate CSV files, combined into a single ZIP archive. | A .zip file holding one delimited .dat file per business object (for example Worker.dat), each with METADATA definitions; spreadsheet loading is also supported. | An Excel workbook downloaded from the application; requires the Oracle ADF Desktop Integration add-in. |
| Typical volume | High. Oracle's FBDI guidance advises up to 100,000 records per import or up to five concurrent imports, and a ZIP file of no more than 250 MB, so large loads are split into batches. | High. Built for bulk loading, data migration, ongoing maintenance and coexistence scenarios where core HR data is uploaded regularly. | Bounded by a user's desktop session. Oracle notes the Create Journals workbook can be used for high-volume journal entry and offers deferred account validation to improve performance. |
| How it runs | Upload the ZIP, run Load Interface File for Import to fill interface tables, then a product import process moves data to application tables. Automatable through the ERP Integration Service (importBulkData) or the Oracle Integration ERP Adapter. | Submit the .zip on the Import and Load Data page, or deliver it through WebCenter Content and the HDL web service. Data is imported to stage tables, then loaded through business-object services, in one step or two. | Interactive. A user downloads the workbook, enters or edits rows in Excel and uploads them; the journals workbook can save to the interface, submit Journal Import, or submit Journal Import and Posting. |
| Validation and errors | If the load fails on any row, the whole batch is rejected; fix the data, regenerate the ZIP and resubmit. Import errors are reviewed in the import log and corrected in ADFdi correction spreadsheets. | Data-type validation on import to stage tables, then object-specific validation by business-object services on load. Errors and failed-line counts are shown on the Import and Load Data page. | Initial validations run in the workbook (for journals, such as a valid accounting date and journal category), and results display in the Status Viewer pane on the worksheet. |
| Best for | Data conversion and recurring high-volume ERP and SCM interfaces. | HCM conversion, bulk maintenance and HR coexistence feeds. | Iterative entry by business users, error correction and controlled post go-live data fixes. |
FBDI: File-Based Data Import
FBDI is the workhorse for high-volume structured data into Fusion ERP. Use it for GL balances, AP and AR transactions, suppliers, customers, items: anywhere you need to load thousands or millions of rows. Oracle describes it as importing data from external sources to interface tables and then to the application tables, with Excel templates that structure and format the data file to match what the target tables require.
How an FBDI load works
- Download the Oracle template for the object, populate it and run its macros to generate CSV files.
- Combine the CSV files into a ZIP archive and upload it to the Oracle WebCenter Content (UCM) server.
- Run Load Interface File for Import, selecting the import process for the object, to move the data into interface tables.
- The product-specific import process validates the data and transfers it from the interface tables to the application tables.
- Review the load and import logs, correct errors, and resubmit or reprocess as needed.
Where FBDI needs care
Two behaviours shape how our teams plan FBDI work. First, the load step is all or nothing: Oracle documents that if the load fails on any row, the loaded rows are deleted and the entire batch is rejected, so files are validated against template rules before upload. Second, volume limits are real. Oracle's guidance recommends up to 100,000 records per import or up to five concurrent imports, a ZIP under 250 MB and off-peak scheduling, so large conversions are split into planned batches with their own control totals.
For recurring interfaces, manual uploads do not scale. The ERP Integration Service exposes a single importBulkData operation over REST and SOAP, and Oracle notes it can issue a callback when all processes complete, with a summary of the execution. That makes FBDI a sound base for scheduled, monitored integrations as well as one-time conversion.
HDL: HCM Data Loader
HDL is the HCM equivalent of FBDI. It is used for workers, assignments, salary, elements, talent and security objects. If you are doing Fusion HCM, you will spend a lot of time in HDL. Oracle positions it for data migration, bulk loading, ongoing maintenance of HCM data and coexistence scenarios where core HR data is uploaded regularly from another system.
How HDL processes a file
Each .zip file contains one or more .dat files, and each .dat file holds data for a single business object, such as Job.dat or Worker.dat. During import, HDL validates the file name and METADATA definitions, loads records into its stage tables, validates them against attribute data types, and groups related date-effective lines into logical objects.
It does not write those objects straight to application tables. Instead it passes valid objects to business-object services, such as the worker service, which apply object-specific validation and load what passes. You can run import and load together or import only and load separately, which is useful when you want to inspect staged data before committing it.
Because validation happens at object level, a single file can partially succeed. HDL reports errors and failed-line counts on the Import and Load Data page, so reconciliation has to account for records that were rejected as well as those that loaded.
ADFDI: ADF Desktop Integration
ADFDI is the spreadsheet-based mechanism. It is best for iterative entry, correction and post go-live data fixes. It is slower at scale than a file-based bulk load, but it suits hypercare workflows. Users work in integrated Excel workbooks that require the Oracle ADF Desktop Integration add-in, create or edit records, and upload them to the application with validation feedback on the worksheet.
The General Ledger Create Journals workbook is a good example. It lets teams prepare journals offline, distribute them for review or save them for recurring entry, and shows validation results in a Status Viewer pane. ADFDI also appears in the FBDI error path: Oracle directs users to correct import errors using ADFdi correction spreadsheets, which keeps fixes inside the application rather than in ad hoc files.
How to choose
- High-volume one-shot loads: FBDI or HDL
- Iterative entry by business users: ADFDI
- Post go-live data fixes: ADFDI with controlled access
- Anything regulated: use whichever leaves a clean audit trail
The choice between FBDI, HDL and ADFDI is decided first by the product area and then by volume and who does the work. HCM objects go through HDL, because it is the loader Oracle provides for HCM business objects and it applies each object's own validation through business-object services. ERP and SCM objects in bulk go through FBDI, because its templates, interface tables and import processes are built for high-volume loads and can be automated through the ERP Integration Service.
ADFDI is the right tool when a person, not a pipeline, is entering or correcting data, because it gives business users an Excel interface with validation feedback and uploads directly to the application. In a typical implementation, conversion uses FBDI and HDL, recurring interfaces use automated FBDI or HDL, and hypercare and day-to-day corrections use ADFDI workbooks under role-based access. Choosing by product area first, then by volume, avoids most rework.
How our teams combine the three
Across our leadership team's more than 15 years of Oracle work, our approach to data conversion is consistent: every load is reconciled back to source, not just checked for errors. For FBDI and HDL that means record counts and financial control totals compared between the legacy extract, the generated file, the interface or stage tables and the application tables, with rejected records tracked to closure. Mock conversions run end to end with the tooling planned for cutover, so batch sizes, run times and error patterns at go-live are already familiar.
After go-live, the emphasis shifts to control: ADFDI workbooks go to named roles for defined correction tasks, recurring FBDI and HDL loads are scheduled and monitored, and the audit trail is part of the design.
Common mistakes
- Using ADFDI workbooks for full conversion volumes because they feel familiar, then running out of time at cutover.
- Treating an FBDI load that completed as proof the data is right, without reconciling to source.
- Leaving broad ADFDI access in place after hypercare with no review of who can change what.