Oracle PeopleSoft and Amazon Seller Central integration

What moves between them

The flow runs from Amazon Seller Central into Oracle PeopleSoft. After each settlement, ml-connector reads the Amazon settlement report and the Finances API events, then posts the resulting journals into the PeopleSoft general ledger through the JOURNAL_ENTRY_CI SOAP service: gross sales, marketplace and FBA fees, refunds, and adjustments, each mapped to the matching business unit and ChartFields. Order and transaction data is also read for line-level reconciliation. Because Amazon settlement is read-only accounting data and PeopleSoft is the system of record, ml-connector does not write financial entries back into Amazon. The cadence follows the Amazon settlement cycle, with a scheduled poll backfilling anything between settlements.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it exchanges the seller refresh token for a one-hour access token, caches it, and refreshes before expiry, sending the marketplace ID and routing to the correct regional base URL. Settlement data is pulled with the async Reports pattern, create the report, poll getReport until DONE, then download the file from the presigned S3 URL, while finer-grained events come from the Finances API following NextToken to the last page. On the PeopleSoft side it accepts the full node URL per customer and sends Basic Auth, since there is no shared hostname, and posts each journal through JOURNAL_ENTRY_CI SOAP because the delivered REST endpoints are read-only. ChartFields and business units are mapped first so every journal line lands on a valid account. The Amazon order or settlement identifier is used as the natural idempotency key so a re-run does not double-post into PeopleSoft. Amazon returns HTTP 429 under its token bucket and PeopleSoft can return 401 or a slow Tuxedo response, so ml-connector backs off and retries on both, and every record carries a full audit trail and can be replayed if a PeopleSoft post fails.

A real-world example

A mid-sized consumer goods manufacturer with roughly 300 employees runs Oracle PeopleSoft Financials for the general ledger and sells finished goods on Amazon through Seller Central using FBA. Before the integration, the accounting team downloaded each Amazon settlement report, split out gross sales, FBA and referral fees, and refunds in a spreadsheet, then keyed the totals into PeopleSoft as a manual journal, and spent the first days of month-end close reconciling the Amazon payout against the revenue it covered. With Oracle PeopleSoft and Amazon Seller Central connected, each settlement posts into the ledger automatically against the right business unit and ChartFields, the marketplace fees are recognized, and the deposit already ties out. The manual re-keying step is gone and close starts from reconciled numbers.

What you can do

• •Post Amazon Seller Central settlement reports into the Oracle PeopleSoft general ledger after every payout.
• •Record gross sales, marketplace and FBA fees, refunds, and adjustments against the correct PeopleSoft business unit and ChartFields.
• •Pull Amazon orders, financial events, and settlement reports through the Selling Partner API, following NextToken and the async report workflow.
• •Bridge Amazon Login with Amazon OAuth2 refresh tokens with PeopleSoft node URL and Basic Auth, posting journals through JOURNAL_ENTRY_CI SOAP.
• •Poll on the Amazon settlement cadence with retries and a full audit trail on every record, because neither side sends a settlement push.

Questions

Which direction does data move between Oracle PeopleSoft and Amazon Seller Central?

The flow is Amazon Seller Central into Oracle PeopleSoft. Settlement reports, sales, fees, and refunds move from Amazon into the PeopleSoft general ledger as journal lines. Amazon settlement data is read-only accounting data and PeopleSoft is the system of record, so ml-connector does not write financial entries back into Amazon.

How are journals written into PeopleSoft when its REST endpoints are read-only?

The delivered PeopleSoft REST services for invoices and procurement are read-only inquiry endpoints, so they cannot create a GL entry. ml-connector posts each journal through the JOURNAL_ENTRY_CI Component Interface exposed as a SOAP service, using the Amazon settlement identifier as a natural key so a retry does not double-post.

Why does the integration poll instead of using webhooks?

Amazon Seller Central only pushes events through EventBridge or SQS, and those notification types do not cover settlement or finance data, so settlements are read with the Reports and Finances APIs on a schedule. Oracle PeopleSoft has no self-service webhooks and is effectively pull-only from a connector, so ml-connector polls both sides on the Amazon settlement cadence and backs off on HTTP 429 or PeopleSoft errors.