Migrate from Oracle Financials Cloud to Microsoft Dynamics 365 Business Central

Oracle Ledgers define currency, accounting calendar, and COA assignment as the top-level financial container. We map each Ledger to a D365 Legal Entity and preserve the accounting calendar as the Legal Entity fiscal calendar configuration. If multiple Ledgers share the same currency and chart of accounts, they can consolidate under a single Legal Entity with separate main accounts for source tracking. Ledger-level reporting configurations in Oracle do not map to D365 equivalents and are included in the reporting rebuild inventory.

Oracle Business Units own AP and AR subledger records and must exist in D365 before any invoice or payment records can be assigned. We sequence Business Unit creation as a pre-flight step, hold all subledger records in a pending state until Legal Entity setup is confirmed complete, and flag any Oracle BU hierarchies that do not map cleanly to D365's flat Legal Entity model. Orphaned subledger records are the most common post-migration reconciliation issue when this sequencing is skipped.

Oracle Financials COA typically uses 4-6 flexfield segments (Company, Division, Department, Account, Product, Project). D365 Finance uses Main Account with up to 10 Financial Dimensions. We detect all active Oracle segments during discovery, build a concatenation strategy for segments that must be preserved in reporting, and flag any segments that can be dropped. The concatenation target (e.g., Company-Dept-Account as a single Main Account with D365 Dimensions for the other segments) is validated against the customer's reporting requirements before migration begins. Oracle segment-value reference tables are preserved as D365 Dimension values.

Oracle Suppliers map to D365 Vendors with address, tax registration, payment terms, and bank account assignments preserved. Supplier sites migrate as Vendor addresses with the same purpose flags (procurement, payment, RFQ). We migrate payment terms as D365 Vendor payment terms and hold tax registration numbers as vendor group or vendor-level attributes for GST/HST and VAT compliance.

Oracle AR customers map to D365 Customers. Bill-to and ship-to addresses migrate as Customer addresses with address purpose flags matching Oracle's site-role assignments. Credit limits, dunning assignments, and payment terms are mapped to D365 Customer credit limits, Collection letter sequences, and payment terms. Dunning groups in Oracle do not have a direct D365 equivalent and are included in the collection policy rebuild documentation.

Oracle AP invoices carry ledger-specific distributions, accrual flags, and validation status. We map invoice distributions by line and account, preserving the account coding from Oracle's multi-segment structure as the D365 Main Account and Dimension values. Unvalidated Oracle invoices are flagged as requiring approval in D365 before posting; their pre-validation status is recorded in a custom field for audit trail continuity.

Oracle AR transactions include revenue lines, tax lines, and receivables distributions tied to the subledger. We map AR transactions preserving customer, amount, and accounting date; inter-company invoices are flagged separately because D365 handles inter-company transactions through Intra-Company journal pairs rather than subledger-level links. Credit memos and debit memos migrate with their reference to the original invoice preserved in the remarks field.

Oracle payments link to AP or AR invoices via payment schedules. We migrate payment records with settlement discounts and withholding tax details, preserving links to source invoices where D365's payment matching can resolve them. For Oracle payments that cannot match D365 invoices due to date or amount rounding, we create a manual payment journal entry with a reference to the Oracle payment number in the narration field.

Oracle assets carry depreciation books, asset categories, assignment records, and financial depreciation histories. We map asset registers and depreciation schedules. Assets with multiple Oracle depreciation books require separate D365 Value Models, and books with different depreciation methods (straight-line vs declining balance) require separate Depreciation books in D365. The net book value in D365 is recalculated from the source depreciation schedule during migration to prevent divergence from Oracle's running balance.

Oracle bank accounts are linked to Payment Process Profiles and Cash Management balances. We map bank account details including branch, account number, currency, and the associated payment format profile. Cash position data in Oracle does not migrate as transactional records; we provide a cash position template populated from Oracle's last available balance date for the customer's Finance team to configure in D365 Cash Management.

Oracle Financials maintains tax registries per tax authority with rates, recovery accounts, and applicability rules. We map tax codes to D365 Tax Groups and Tax Codes, flagging compound tax structures (multi-component VAT, cascading GST) that require D365 Tax setup beyond the standard code assignment. Tax authority details migrate as vendor records for withholding tax agents.

Oracle journal entries are posted to ledgers with journal categories, sources, and approval statuses. We migrate approved and posted journals within configurable date scopes. Unposted journals do not migrate; we deliver them as a reference spreadsheet for manual re-entry in D365 if needed. Recurring journal templates migrate as D365 Journal templates with the same frequency and amount parameters.

Oracle Cost Centers exist as independent flexfield segments or as part of the HRMS organization hierarchy depending on implementation choices. We identify the source and map cost center assignments to D365 Financial Dimensions with a dedicated Cost Center dimension. The dimension value list is populated from Oracle's active Cost Center segment values. If Cost Centers are HRMS-owned in Oracle, the organization hierarchy does not migrate; we document the HR-to-Finance mapping as a post-migration configuration task.

Expense report headers and line items migrate with their cost center and project assignments. Oracle expense mileage reimbursement rates and per-diem policy calculations are stored as configuration rather than transaction data and do not transfer as calculated amounts. We export the source rate tables as reference data and deliver them as a D365 expense policy configuration document for the customer's admin to rebuild with the current rates post-migration.