For data & ERP teams on Oracle Fusion Cloud

Know exactly which Oracle Fusion data you need — and run it in your own cloud.

Stop spending weeks guessing where Fusion keeps your data. Query it, find it and prove it in minutes with a free SQL editor — then turn it into a pipeline that runs in your AWS or Azure account.

What happens next: we reply within one business day with access. You sign in with your own Fusion user; queries run read-only through Oracle BI Publisher. Nothing to install.

Your Fusion dataYour cloudYour architecture
SELECT name, ledger_category_code, currency_code
FROM gl_ledgers
FETCH FIRST 100 ROWS ONLY
-- runs through BI Publisher, results in seconds
3 rows · 3 columns
NAMELEDGER_CATEGORY_CODECURRENCY_CODE
US Primary LedgerPRIMARYUSD
UK Primary LedgerPRIMARYGBP
US Secondary (IFRS)SECONDARYUSD
SELECT * FROM pvo:SupplierExtractPVO
WHERE Status = 'ACTIVE'
LIMIT 100
-- the same extract your pipeline will deliver
100 rows · 143 columns · same shape as your warehouse table
SUPPLIERIDSUPPLIERNAMESTATUS
300000101134Acme CorpACTIVE
300000203847Global IndustriesACTIVE
search the data dictionary
? "bill rate"
-- 615K described columns across 4,545 PVOs
Top matches
PVOCOLUMN
BillingTransactionExtractPVOPjbBillTransactionsBillRate
RevenueDistributionExtractPVORevenueDistributionPEOBillRate
InvoiceDistributionExtractPVOInvoiceDistributionPEOBillRate
-- paste an EBS R12 query
SELECT ai.invoice_num, ai.invoice_amount, pv.vendor_name
FROM ap_invoices_all ai JOIN po_vendors pv
  ON pv.vendor_id = ai.vendor_id
2 R12 tables → 2 Fusion PVOs · add to model
R12 TABLEFUSION PVOMODULE
AP_INVOICES_ALLInvoiceHeaderExtractPVOPayables
PO_VENDORSSupplierExtractPVOProcurement
550PVOs running in production
~3Mrows delivered per day
30 minincremental cadence
4,545PVOs catalogued, 615K columns
How we access Oracle Fusion
Your own credentialsA least-privilege Fusion user — no database login, no Oracle admin access.
Read-only discoveryThe editor queries through Oracle BI Publisher and extraction APIs. It never writes to Fusion.
Production stays in your cloudPipelines, credentials and business data run in your AWS or Azure account.
ReviewableWe walk your security team through every data flow. Details →

One platform for the whole Fusion data lifecycle

Most tools start once you already know what to extract. FusionConvergeX starts earlier — and stays through production.

DiscoverFind and prove the right Fusion data
MapTranslate R12 logic to Fusion sources
BuildDefine extraction as code, deploy to your cloud
OperateIncrementals, alerts, delivery checks

Product status: Available generally available   Beta in use with customers, evolving   Preview early access   Roadmap planned

Built for the hard part of Oracle Fusion data

Generic ELT platforms can move data once the source is known. FusionConvergeX helps you decide what Fusion data to use, how legacy EBS data maps to it, how extraction should be modeled — and how it is deployed and operated in your enterprise platform.

We don't replace your lakehouse.
We make Oracle Fusion understandable to it.
Practice 1 · Fusion Discovery

Find the right Fusion data — and prove it's there

A free SQL editor and a catalog of every Fusion PVO, so the question “which source has this?” takes minutes, not weeks. In the browser or on the desktop (macOS & Windows).

SQL

Table SQL in seconds

Query Fusion tables and views read-only through Oracle BI Publisher with your own credentials. Nothing to install.

Free Available
PVO

PVO SQL

SELECT * FROM pvo:… runs the same extraction a pipeline will run — validate the data before you build anything.

Free Available
?

Find any column

Search 615,000 described columns across 4,545 PVOs and 22 modules to find where Oracle keeps the field you need.

Free Available
R12

PVOs from R12 SQL

Paste an EBS R12 query and see which Fusion PVOs it needs, table by table.

Free Beta
PVO Selector
01

PVO Explorer Available

All 4,545 PVOs with described columns — primary keys and incremental watermark columns flagged.

02

SQL & base tables behind each PVO Available

See the Oracle SQL a PVO generates and the Fusion tables it reads; go from a table to its PVOs and back.

03

Schema versions & diff Available

Track PVO columns across Oracle releases and instances before a quarterly update breaks a load.

04

Flexfields per environment Available

Map DFF segments per client and instance so custom fields arrive with business names.

AI

Start from the business question Roadmap

Describe the data you need — “project billing-rate overrides with employee, project, task and effective dates” — and get grounded recommendations: Fusion entities, sources, keys, watermarks and a draft YAML model, all from our Fusion metadata.

Prove the data before you build the pipeline
-- Is the data really here, and how much?
SELECT COUNT(*) FROM pvo:BillingTransactionExtractPVO

-- Which columns are actually populated?
SELECT * FROM pvo:ExpenditureItemExtractPVO LIMIT 500

-- Does it tie out to the R12 report?
SELECT ProjectBasePEOSegment1, ProjectBasePEOName
FROM pvo:ProjectExtractPVO
WHERE ProjectBasePEOSegment1 = '4588804'

-- Will incremental work? Check the watermark
SELECT MAX(ProjectBasePEOLastUpdateDate) FROM pvo:ProjectExtractPVO
Confirm the source holds your dataRow counts and sample rows from your own instance, not a documentation guess.
Find empty and default-off columnsSelect only the columns that are genuinely populated.
Check keys, watermarks and deletesThe things incremental loads depend on, verified up front.
Catch problem sources earlyWide PVOs that fail, or return nothing under the extraction user's security, show up now — not in production.
What this means for your team
  • Source decisions backed by real row counts, not documentation
  • No surprise empty columns in the warehouse
  • Weeks of mapping workshops become an afternoon
Featured Practice 2 · Migration Engineering

Rebuild your EBS R12 reporting and data flows on Fusion

Years of R12 SQL already describe the data your business depends on. We turn that knowledge into Fusion sources, an extraction model and a target data model — so reporting continuity isn't a rewrite from scratch.

1

Analyze R12 SQL Beta

Bring existing queries and reports. We identify the R12 tables and columns they use (AP_INVOICES_ALL, PA_EXPENDITURE_ITEMS_ALL, …).

2

Map to Fusion Beta

Each R12 table and column is mapped to Fusion tables and the PVOs that expose them — with gaps flagged where Fusion has no equivalent.

3

Reconcile Beta

Run the PVO next to the R12 query it replaces and prove the numbers tie out before sign-off.

4

Model the target Available

Start from 489 Fusion subject-area star schemas to shape the warehouse your R12 reports are rebuilt on. Browse the library →

Paste R12 SQL. Get the Fusion sources.
EBS R12 tableFusion PVOModuleNotes
AP_INVOICES_ALLInvoiceHeaderExtractPVOPayablesHeader columns map 1:1 for most reports
PO_VENDORSSupplierExtractPVOProcurementVendor → supplier model; sites split out
PA_PROJECTS_ALLProjectExtractPVOProjectssegment1, name, status carried in the YAML
PA_EXPENDITURE_ITEMS_ALLExpenditureItemExtractPVOProjectsWide PVO — curated column list
GL_CODE_COMBINATIONSCodeCombinationExtractPVOGeneral LedgerSegments differ per chart of accounts
PA_EMP_BILL_RATE_OVERRIDESNo direct PVOProjectsGap flagged — alternate source proposed
What this means for your team
  • Your existing R12 reports become the requirements document
  • Gaps are found in week one, not in UAT
  • Every Fusion column traces back to the R12 query that needed it

EBS R12 → Fusion Beta

Traceability from each Fusion column back to the R12 query that needed it — kept in the same YAML model that drives extraction, so migration decisions are reviewable and versioned.

BICC → Oracle Data Extraction Roadmap

Oracle now documents BICC as legacy and its RODS-based Data Extraction tool as the replacement. What to do next → Because your model is defined independently of the extraction engine, the plan is to let the same model run on either — preserving your downstream Databricks and Snowflake tables through the transition.

Practice 3 · Data Engineering

Define extraction as code. Run it in your cloud.

An intelligence and model layer above Oracle's extraction engines — delivering into the platform you already run.

Oracle Fusion CloudERP · HCM · SCM · Projects
FusionConvergeXmetadata intelligence · YAML model · orchestration
Oracle extraction engine
BICC  AvailableData Extraction (RODS)  Roadmap
Your cloudS3 · ADLS · GCS
Your platformDatabricks · Snowflake · BigQuery

Extraction engines are execution targets; your model, dependencies and downstream tables stay stable.

modules:
  - name: project_accounting
    groups:
      - group: projects_l1
        depends_on: [enterprise_setup_l0]
        pvos:
          - pvo: FscmTopModelAM.PrjExtractAM.PjfBiccExtractAM.ProjectExtractPVO
            target_table: project
            primary_key: [ProjectBasePEOProjectId]
            watermark: [ProjectBasePEOLastUpdateDate]
            delete_mode: soft
            columns: [ProjectBasePEOProjectId, ProjectBasePEOSegment1, …]
            # from R12: PA_PROJECTS_ALL (segment1, name, project_status_code)

Extraction as code

  • Every column choice is reviewed and versioned
  • Jobs rebuilt exactly from the model — including default-off columns
  • Dependencies live in the YAML (depends_on) and drive load order
  • Incremental state tracked outside the extraction engine, with self-healing watermarks
  • Same model promotes DEV → TEST → PROD
YAML-based configuration

A true CI/CD pipeline architecture — for your Fusion data

The whole pipeline — sources, columns, keys, watermarks, dependencies, schedules and destinations — lives in git and ships like software. No console clicks, no configuration drift, every change reviewed and reversible.

  1. CommitAdd a source or column in YAML, open a pull request
  2. ValidateAutomated checks: schema, keys, watermarks, dependency order
  3. Deploy DEVExtraction jobs are built from the model and run
  4. PromoteSame YAML to TEST and PROD — only environment settings change
  5. Roll backRevert the commit; jobs are rebuilt exactly as before
Deployment kit — your cloud, your code
Step AYour selected sourcesPVOs, columns, keys, dependencies → YAML
Step BGenerated deployment kit~90% ready to run, out of the box
Step CYour customizationsNaming, networking, security, schedules
Step DRuns in your cloudAWS · Azure Available
GCP Preview

FusionConvergeX generates a deployment kit for AWS and Azure (GCP in preview): infrastructure templates plus pipeline code, wired to your YAML model. It covers roughly 90% of a production deployment; the rest is plain, readable code in your repository to adapt to your standards.

Production data pipelines run entirely in your cloud. FusionConvergeX provides the design and discovery experience; production extraction, production credentials, business data and pipeline execution remain in infrastructure you control — with no dependency on us to keep them running.
  • Available Infrastructure-as-code — landing storage, serverless functions, scheduler, secrets, least-privilege roles
  • Available Extraction & delivery code — job generation, watermark registry, dependency-ordered waves, multi-destination delivery
  • Available Your YAML model  ·  Beta CI/CD wiring
  • Available Operator CLI — fcx and bicc-pipeline for jobs, loads, watermarks and recovery
  • Available Monitoring & runbook — alarms, delivery checks, row-count reports, day-2 operations
Operate it reliably — day 2 and beyond
1 · DiscoverProve the dataSQL editor, PVO catalog, R12 mapping
2 · ModelYAML in gitSources, keys, watermarks, dependencies — reviewed like code
3 · DeployKit in your cloudGenerated infrastructure + pipeline code in your account
4 · MonitorVerified every runRow counts, delivery checks, alerts, rollback

Incremental loads

An explicit time window on every extract, driven by your own watermark registry. Full reloads are one command.

Dependency-ordered waves

Reference data lands before the facts that depend on it — and load stays gentle on your network.

Verified delivery

Every run is checked end-to-end; any gap raises an alert and a per-source row-count report goes out after each run.

Rewind & recover

Reset a watermark, backfill a window or re-send a delivered run with one command — and roll back model changes by reverting the commit.

# build every extraction job from the YAML model
$ fcx job create-from-yaml --all --model pvo_model.yaml
# preview, then apply schedules
$ bicc-pipeline schedule plan
$ bicc-pipeline schedule apply
# incremental load for a cadence, then check it
$ fcx fire --cadence every_2h
$ fcx rowcount ProjectExtractPVO --date 2026-09-26
# fix a watermark, re-send a delivered run
$ fcx watermark seed ProjectExtractPVO "2026-09-01 00:00:00"
$ bicc-pipeline republish
Buildfcx job create-from-yamlfcx describe <pvo>
Schedulebicc-pipeline schedule plan | applyfcx schedule status
Run & recoverfcx fire | backfillbicc-pipeline rewind | republish
Observefcx rowcountbicc-pipeline status | history
Security & trust

Your Fusion data. Your cloud. Your architecture.

Production data pipelines run entirely in infrastructure you control; the discovery experience is hosted by us. Here is exactly what lives where.

WhatWhere it lives
Business data (extracts)Your cloud storage and data platform only
Production credentialsYour own vault / secret manager
Pipeline code & YAML modelYour git repository and cloud account
Production pipeline executionYour cloud account only
SQL editor & catalog (discovery)Hosted by FusionConvergeX
Fusion credentials used in the editorUsed only to run your read-only queries — we recommend a dedicated least-privilege discovery user, never a production service account
Least privilege. For current BICC-based extraction, a least-privilege Fusion service account with the required BICC and BI Publisher permissions is sufficient — no Fusion database login is required. Oracle Data Extraction (RODS) permissions will be documented separately as support becomes available.
Scoped cloud roles. Each component can read only the bucket, secret or destination it needs.
Full audit trail. Every run, row count and delivery is logged and reported.
Security reviews. We walk your security team through the architecture and data flows.
In production · enterprise Oracle Fusion customers

Fusion to Azure, Databricks, AWS and Snowflake — every 30 minutes

Finance, projects, HR, procurement, supply chain and tax data flows from Oracle Fusion Cloud into customers' data lakes, Databricks and Snowflake on a 30-minute incremental cadence — dependency-ordered from the YAML model, fanned out to several environments at once, and verified after every run.

AzureDatabricksAWSSnowflake
550PVOs in production
~3Mrows delivered per day
30 minincremental cadence
4target platforms

Built by Oracle Fusion data engineers

FusionConvergeX is built by practitioners who run these pipelines in production — the same engine, YAML model and runbooks we sell. Enterprise references available on request.

Meet the foundersAsk for a reference

Where FusionConvergeX fits

A comparison of primary focus by category — not a claim about what any product can do with customization.

Generic ELT / connectorsOracle-managed analyticsFusionConvergeX
Deciding what Fusion data to useAssumes you knowPrebuilt subject areasDiscovery, PVO SQL, column search
EBS R12 → Fusion mappingNoNoR12 SQL → PVOs, reconciliation
Extraction model as code (git, CI/CD)Connector configOracle lifecycleYAML model
Runs in your own cloudUsually SaaSOracle stackAWS, Azure, GCP
Keeps your Databricks / Snowflake architectureYesOracle lakehouseYes
Pricing basisRows / volumeOracle subscriptionFlat, by environment
Application integrationBoomi · MuleSoft · Oracle Integration Cloud

Move business transactions between applications.

vs
Fusion data engineeringFusionConvergeX

Engineer Oracle Fusion data into your enterprise data platform.

Start free. Scale to production.

Discovery is free. Production packages are priced by environment and scope — never per row.

Free — no credit card

  • SQL editor: table & PVO SQL
  • Column search across 4,545 PVOs
  • R12 SQL → PVO lookup
  • Community guides

Paid — when you go to production

  • Deployment kit generated for your cloud
  • YAML model, CI/CD wiring & environment promotion
  • Incremental orchestration, monitoring & row-count reports
  • Support, security review & onboarding
Explorer
$0
For consultants, developers and analysts
  • SQL editor: table & PVO SQL
  • Column search & PVO Explorer
  • R12 SQL → PVO lookup
  • Web & desktop
Request free access
Team
Contact us
For discovery & migration projects
  • Everything in Explorer
  • Saved YAML models & git
  • R12 mapping & reconciliation
  • Non-production deployments
Talk to us
Production
Contact us
For data teams running Fusion pipelines
  • Everything in Team
  • Deployment kit: AWS, Azure (GCP preview)
  • Incremental orchestration
  • Monitoring & delivery checks
  • Support
Talk to us
Enterprise
Custom
For large organizations and partners
  • Multi-environment governance
  • Security review support
  • Private deployment
  • Priority support & SLA
Contact sales

Questions

Is FusionConvergeX a SQL editor or a pipeline tool?

Both, and more: it covers the Fusion data lifecycle from discovery (SQL editor, PVO catalog) through R12 → Fusion migration engineering to data engineering (extraction as code, deployment into your cloud, monitoring). The SQL editor is free to start.

What's the difference between table SQL and PVO SQL?

Table SQL runs against Fusion tables and views through BI Publisher and returns in seconds. PVO SQL (FROM pvo:…) runs an extraction of a Public View Object — the same one your pipeline loads — so you can validate exactly what will be delivered.

What runs on your side, and what runs in ours?

Production data pipelines run entirely in your cloud: the deployment kit, production extraction, production credentials, business data and pipeline execution all stay in infrastructure you control. FusionConvergeX hosts the design and discovery experience — the SQL editor and catalog. Use a dedicated, least-privilege, read-only Fusion user for discovery; production credentials never leave your cloud.

Oracle is replacing BICC with the Data Extraction tool. What does that mean for us?

Your YAML model describes sources, columns, keys and dependencies independently of the extraction engine. BICC is supported today; support for Oracle's RODS-based Data Extraction tool is on our roadmap, with the goal of keeping your downstream tables unchanged through the transition.

How is this different from a data connector like Fivetran?

Connectors solve data movement once you know the source. FusionConvergeX solves the Oracle Fusion engineering problem around it: deciding what to extract, mapping legacy EBS data to Fusion, modeling the extraction, deploying it into your architecture and operating it. The two can work together — FusionConvergeX can define and validate what a downstream tool moves.

Is this an integration platform like Boomi, MuleSoft or OIC?

No. Integration platforms move business transactions between applications. FusionConvergeX engineers Oracle Fusion data into your enterprise data platform for analytics, reporting and AI.

Do I need Oracle admin access?

No. For current BICC-based extraction, a least-privilege Fusion service account with the required BICC and BI Publisher permissions is sufficient — no Fusion database login. Permissions for Oracle Data Extraction (RODS) will be documented as support becomes available.

Which clouds and platforms do you deliver to?

AWS and Azure today, with GCP in preview — and the platforms built on them, including Databricks, Snowflake and BigQuery. One pipeline can deliver to several environments at once.

Make Oracle Fusion understandable to your data platform.

Start with the free SQL editor. When you're ready for production, we'll help you deploy.

Get the free SQL editor Book a demo