Oracle Fusion Cloud ERP and Amazon Seller Central integration

What moves between them

The primary flow runs from Amazon Seller Central into Oracle Fusion. New and updated orders from Amazon are read every 5 to 15 minutes and posted as receivables invoices in Oracle Fusion, with revenue distributed to GL accounts mapped from the seller's product catalog. Financial settlement events, refunds, and adjustments from Amazon are retrieved and posted to Oracle Fusion journal batches for the appropriate cost centers and revenue accounts. Customer and product master data can flow bidirectionally, with Oracle Fusion customer records matching Amazon seller profiles and product catalogs aligning to Amazon catalog items. Refunds and cancellations in Amazon reverse the corresponding revenue and invoice lines in Oracle Fusion.

How ml-connector handles it

ml-connector stores the Amazon refresh token encrypted and uses it to obtain access tokens hourly, refreshing before the token expires at the 3600 second mark. On the Oracle Fusion side, it accepts the pod and region parameters specific to each customer's instance and authenticates with OAuth2 client credentials against that pod's OCI Identity Domain, caching the resulting JWT bearer token for approximately one hour. It polls the Amazon Orders API and Finances API at a cadence matching your fulfillment and settlement cycle, filtering by creation and update timestamps to avoid duplicate reads. Each order maps to an Oracle Fusion receivables invoice with GL distribution determined by the product catalog mapping file; settlement events post to journal batches tagged with the seller's legal entity and cost center. Amazon returns Orders older than two years only in select regions, so ml-connector respects those regional date boundaries and flags records outside the retention window. Rate limiting on both sides is handled with exponential backoff and jitter. Every record carries a full audit trail, including the Amazon Order ID and Settlement Event ID, so any downstream discrepancy can be traced and replayed if needed.

A real-world example

A mid-sized seller operates a multi-channel product business across Amazon, direct e-commerce, and retail partnerships, with Oracle Fusion handling consolidated accounting and cost of goods sold at a central hub. Before the integration, the finance team downloaded Amazon settlement reports and order exports daily, manually mapped order IDs to customer accounts and product lines in Oracle Fusion, and entered revenue and COGS accruals by hand, a process that introduced delays, reconciliation errors, and month-end firefighting when Amazon refunds or canceled orders did not match the GL. With Oracle Fusion and Amazon Seller Central connected, every order posts as a receivables invoice immediately upon fulfillment, settlement events flow into the GL automatically allocated to the correct revenue and cost accounts, and refunds reverse the corresponding lines. The finance team now performs reconciliation of Amazon settlement totals to GL postings as a validation step rather than as data entry, and visibility into orders to cash is real-time.

What you can do

• •Post Amazon orders as receivables invoices in Oracle Fusion, allocated to the correct GL accounts based on product and region.
• •Stream settlement events and refunds from Amazon into Oracle Fusion journal batches for accurate revenue recognition.
• •Map Amazon refresh tokens and Oracle Fusion pod URLs per seller, with hourly OAuth2 token refresh on both sides.
• •Poll Amazon Orders and Finances APIs on a schedule matching your fulfillment and settlement cadence, with automatic retries on rate limits.
• •Maintain a complete audit trail linking each Oracle Fusion transaction back to the Amazon Order ID or Settlement Event ID for reconciliation and replay.

Questions

How does the integration handle the fact that Amazon has no direct HTTP webhooks?

ml-connector polls the Amazon Orders API and Finances API every 5 to 15 minutes, filtering by creation and update timestamps to retrieve only new and changed records. Financial settlement events and refund data cannot be pushed by Amazon and must always be polled, so a scheduled polling approach covers both orders and settlements in a single cadence.

What happens when an order is refunded or canceled in Amazon?

ml-connector retrieves the refund or cancellation event from the Amazon Finances API and posts a reversing entry to the corresponding Oracle Fusion receivables invoice or GL journal line. The original Order ID and refund event ID are preserved in the audit trail so the finance team can trace the change and reconcile the impact.

How are product categories and GL accounts mapped between the two systems?

Each seller provides a product catalog mapping file that correlates Amazon product categories or SKUs to Oracle Fusion GL accounts and cost centers. ml-connector uses this mapping when posting order revenue and COGS so that every dollar lands on the intended account. If a product is not in the mapping, the record is flagged for manual review rather than posting to a default account.