The complete finance footprint: OJDT/JDT1 to Fusion GL, OINV to AR, OPCH to AP, OFA to Assets, OPRC cost centres, OMRC multi-currency, OBNK banking. Sub-ledger reconciliation, parallel run, sign-off tolerance, statutory reporting validation.
The other workstreams matter — but finance is the one the CFO signs off on, the one the auditor validates, and the one whose failure is most visible and most expensive.
When a SAP Business One → Oracle Fusion migration is in flight, every workstream feels critical to its workstream lead. But ask any CFO who has been through one of these and they'll tell you: finance migration is the workstream that decides whether the programme is judged a success. If finance migrates clean — trial balance reconciles to well under 0.01% variance, sub-ledger-to-GL ties out at month-end, statutory reports produce numbers that match the prior B1 statutory submissions, parallel-run close cycles produce equivalent results — the programme is a success and other workstreams' issues are tolerable.
If finance migration goes wrong — opening balances don't reconcile, AR aging looks different from what B1 showed, AP cycle produces a different liability number, fixed assets net book value doesn't match the source register, multi-currency revaluation produces a different gain/loss — then no amount of success elsewhere recovers the perception. The CFO doesn't sign off, the auditor flags it, and the programme is remembered as the one that 'broke the books'.
Syntra ETL's SAP Business One finance migration approach treats this workstream as the gate that controls the rest of the programme. Each finance sub-domain (GL, AR, AP, Assets, Cost, FX, Banking) has its own playbook, its own reconciliation rules, its own sign-off tolerance, and its own parallel-run validation. Cutover doesn't happen until finance signs off — and finance sign-off is anchored to numerical tolerances, not opinion.
Each sub-domain has its own mapping rules, validation methodology, and sign-off criteria. Generic 'finance migration' as a single thing doesn't work — these are seven different problems that share data.
Chart-of-accounts mapping locked first (OACT → Fusion COA). All OJDT/JDT1 journals migrated preserving date, doc number, sub-ledger source, multi-currency amounts. Validation: trial balance variance < 0.01% per period.
OPCH invoices + OPOR POs + OPDN GR-POs + OVPM payments → Fusion AP. Open liabilities migrated as live AP, paid history to archive. Validation: AP aging buckets reconcile, vendor balances match.
OINV invoices + ORCT payments + ORDR orders + ODLN deliveries + ORIN credit memos → Fusion AR. Open receivables live, paid history archived. Validation: AR aging buckets reconcile, customer balances match.
OFA register → Fusion Assets with current NBV as opening. OFAR history archived. Fusion takes over depreciation post-cutover. Validation: NBV matches, depreciation expense projection matches B1 forward-looking calculation.
OPRC/OCST dimensions → Fusion ledger segments. Allocation rules rebuilt in Fusion allocation engine with B1 logic preserved as documentation. Validation: profit centre P&L reconciles, allocation amounts match.
OMRC rate history loaded to Fusion currency rate manager. Doc/Local/System amounts preserved on every journal line. Revaluation history migrated as tagged journals. Validation: FX revaluation roll-forwards match.
From kickoff through parallel run to cutover. Each phase has explicit entry and exit criteria — no phase progresses until finance signs off on the prior phase.
OACT → Fusion COA mapping (1:1 typical, with occasional consolidations of legacy redundant accounts). OMRC rate history extracted and loaded to Fusion currency rate manager. Baseline B1 trial balance snapshot taken at month-end as the reconciliation reference.
All OJDT/JDT1 journals migrated to Fusion GL with sub-ledger source preserved. Multiple full reconciliation cycles against B1 trial balance. Sub-ledger reconciliation rules built. Phase exit: trial balance variance < 0.01% per period across full history.
Sub-ledger migrations executed: open AR, open AP, fixed assets at current NBV, open banking. Sub-ledger-to-GL reconciliation validated. Open items aging matches B1 aging. Phase exit: each sub-ledger reconciles to GL within sub-ledger-specific tolerance.
OPRC/OCST migrated to Fusion ledger segments. Allocation rules rebuilt in Fusion allocation engine. If Project Costing in scope, project master and project transactions migrated. Statutory reporting validation begins. Phase exit: profit-centre P&L reconciles, allocations match.
2–3 close cycles run in both B1 and Fusion. Finance team produces month-end in both systems. Variance analysis. Tolerances set in advance by CFO (typical: P&L < 0.05%, balance sheet < 0.01%, sub-ledger aging < 0.1%). Phase exit: parallel run produces equivalent results across two consecutive close cycles.
Final cutover at month-end. Opening balances loaded as the migrated trial balance position. First post-cutover close run entirely in Fusion. Hypercare team in place for first three close cycles. CFO sign-off after third post-cutover close. B1 instance scheduled for decommissioning with archive verified.
Concrete artefacts produced and handed over across the finance workstream. The CFO-defensible evidence pack that backs the sign-off.
OACT to Fusion chart-of-accounts mapping, account-by-account, with consolidations and exceptions explicitly noted. Approved by CFO before GL migration runs.
Period-by-period trial balance reconciliation B1 vs Fusion across full historical scope. Variances per account explained, all under tolerance. Auditor-grade evidence.
AR, AP, Assets, Banking sub-ledger reconciliations to GL, both in B1 (pre-migration) and Fusion (post-migration). Aging bucket-level reconciliation evidence.
OMRC rate history loaded, Doc/Local/System amounts preserved, revaluation roll-forward B1 vs Fusion variance < tolerance. FX gain/loss reconciliation.
Profit-centre and cost-centre P&L reconciliation B1 vs Fusion. Allocation rule documentation and Fusion implementation parity validation.
2–3 close cycles run in both systems, variance analysis per close, CFO sign-off with explicit tolerance acknowledgement. The artefact that authorises cutover.
SAP Business One finance migration covers the complete finance footprint of a B1 deployment migrated into Oracle Fusion Financials Cloud. That means the General Ledger (OJDT/JDT1 journal entries → Fusion GL_JE_HEADERS/GL_JE_LINES with subledger accounting reconstruction), Accounts Payable (OPCH AP invoices, OVPM outgoing payments, OPOR purchase orders, OPDN goods receipt POs → Fusion AP), Accounts Receivable (OINV AR invoices, ORCT incoming payments, ORDR sales orders, ODLN deliveries, ORIN credit memos → Fusion AR), Fixed Assets (OFA fixed assets register and OFAR depreciation → Fusion Assets), Cost Accounting (the OPRC/OCST profit centre and cost centre framework → Fusion Cost Accounting with allocation rules), Multi-Currency (OMRC exchange rates and revaluation history → Fusion's currency rate manager), and Banking (OACT cash accounts, OBNK bank master, OCRC reconciliation → Fusion Cash Management). Each sub-domain has its own table mapping, validation strategy, and reconciliation methodology in the SAP Business One finance migration playbook.
Journal entries are the foundation of the SAP Business One finance migration. Every OJDT header with its JDT1 lines is converted to Fusion's GL_JE_HEADERS/GL_JE_LINES structure with full preservation of the original transaction date, posting date, document number (mapped to source-reference), and audit metadata (creator user, creation date, last-modified). Sub-ledger context is preserved: AR-source journals carry the source OINV DocEntry as a sub-ledger reference, AP-source journals carry OPCH DocEntry, and so on. The chart of accounts mapping (OACT to Fusion COA) is a separate work product locked before the journal migration runs — typically a 1:1 mapping with occasional account consolidations where the source COA had legacy redundancies. Multi-currency posting amounts are preserved at the originally-posted FX rate, with revaluation history kept separately so Fusion's revaluation engine can take over cleanly post-cutover.
OINV AR invoices and their INV1 lines are converted to Fusion AR_INVOICES/AR_INVOICE_LINES with full preservation of customer (OCRD CardCode mapped to Fusion Party Number), document number, document date, due date based on OINV payment terms (mapped to Fusion AR payment terms), tax detail per line (OINV1 LineTax mapped to Fusion AR tax distributions), currency, and posted amounts. AR statements through ORCT (incoming payments) are migrated separately with payment-to-invoice application history preserved so customer aging reports in Fusion match what B1 reported. Credit memos (ORIN), down payments (DPI1 in B1), and unallocated payments are all handled with explicit migration patterns. Open invoices at cutover (unpaid, partial paid) become open Fusion AR invoices with the correct outstanding balance and aging bucket. Historical (fully-paid) invoices migrate to the archive layer to keep the live Fusion AR module clean while preserving full historical access.
Fixed Assets is one of the more complex SAP Business One finance migration sub-domains because B1's OFA fixed assets register and OFAR depreciation history have to be reconciled into Fusion Assets' more sophisticated lifecycle model. The migration extracts each B1 fixed asset (cost, salvage value, useful life, depreciation method, capitalisation date, current accumulated depreciation, net book value), maps to a Fusion asset book and asset category, and loads with the current net book value as the opening position. Historical depreciation is preserved in the archive (so 'how much depreciation did we book on this asset in 2019?' can still be answered) but doesn't replay in Fusion — Fusion takes over depreciation from cutover forward. Tax depreciation books (relevant where the SMB tracks both accounting and tax depreciation separately for jurisdictional reasons) are handled with parallel asset books in Fusion. Disposals and partial retirements from B1 history are migrated to the archive.
B1 stores three amounts on every journal line: document currency (Doc), local currency (LC, the company's functional currency), and system currency (SC, typically also local but can differ in some setups). Each currency-conversion is at the FX rate effective on the posting date, stored in OMRC. The SAP Business One finance migration preserves all three amounts on the corresponding Fusion GL lines. The Fusion currency rate manager is loaded with the complete historical OMRC rate table so reports that span pre- and post-cutover periods produce consistent FX-translated comparatives. Period-end revaluation history (which B1 stored as adjusting journals tagged with revaluation source) is migrated as journal entries with a revaluation-source attribute so Fusion's revaluation engine knows the FX history and can produce continuous revaluation roll-forwards from cutover onward.
B1's cost-accounting model is dimension-based: each journal line can carry profit centre, cost centre, and project tags (the OPRC and OCST master tables, with the dimension values stored on OJDT/JDT1). SAP Business One finance migration maps B1 profit centres to Fusion's GL ledger segments (typically a 2nd or 3rd segment of the Fusion chart of accounts), cost centres to a dedicated cost-centre segment, and projects to either Fusion's Project Costing module (if the SMB will use it) or to a project segment of the GL chart. Allocation rules that B1 ran on a monthly basis (a typical pattern: allocate overhead from a holding cost centre to revenue-producing cost centres by a headcount or revenue-based driver) are rebuilt in Fusion's allocation engine, with the source B1 logic preserved as documentation alongside the Fusion implementation.
B1's banking footprint includes OBNK (bank master), the cash accounts within OACT, OCRC (bank reconciliation records), and the linkage of payments (OVPM and ORCT) to bank statements. SAP Business One finance migration converts these to Fusion Cash Management's structure: bank master goes to Fusion's bank registry, cash accounts get mapped to Fusion bank account configurations, bank statement formats (BAI2, MT940, CSV, etc.) that B1 ingested via partner integrations are re-implemented as Fusion bank statement imports, and the reconciliation history is preserved both in the live Fusion module (open recon items still being worked at cutover) and in the archive (historical reconciliations). Bank fee accounting, FX gain/loss on bank revaluation, and intercompany cash transfers all have explicit migration patterns.
For a typical mid-market SMB with one to three legal entities, single-country to two-country footprint, 5–10 years of historical data, and standard B1 finance customisation, the SAP Business One finance migration workstream runs 6–9 months. Months 1–2: chart of accounts mapping, sub-ledger account analysis, FX rate history extraction, baseline reconciliation. Months 2–4: GL build and validation (with multiple full reconciliation cycles against B1 trial balance, with tolerance typically required at well under 0.01% variance). Months 3–5: AR, AP, Fixed Assets, Banking sub-ledger migrations with sub-ledger-to-GL reconciliation. Months 5–7: cost-accounting and project migrations, statutory reporting validation, multi-entity consolidation testing. Months 7–9: parallel run (typically 2–3 close cycles run in both B1 and Fusion with sign-off variance limits), final cutover, hypercare. The finance workstream usually drives the overall programme timeline — getting it right is what makes the whole migration succeed.
GL, AR, AP, Fixed Assets, Cost Accounting, Multi-Currency, Banking — seven sub-domain playbooks, each with its own validation methodology and sign-off tolerance. Trial-balance variance under 0.01%, sub-ledger reconciliation evidence, parallel run sign-off, auditor-grade pack.