Which direction does data move between Oracle PeopleSoft and Avalara?

The main flow is Oracle PeopleSoft into Avalara. Vouchers and sales documents move from PeopleSoft to Avalara for tax calculation, and the calculated tax returns and is written back onto the PeopleSoft voucher. Avalara holds no vendor, purchase order, or GL records, so nothing accounting-related is mastered there.

How does the integration avoid posting the same transaction to Avalara twice?

Avalara uses the document code on a transaction as its idempotency key. ml-connector sends each PeopleSoft document number as that code and posts with createOrAdjust, so a retry updates the same uncommitted transaction instead of creating a duplicate. Once a transaction is committed its code is reserved, so ml-connector reconciles by document number before any re-post.

Do I need webhooks on either side for this to work?

No. Neither system pushes events: Avalara has no outbound callbacks and PeopleSoft has no conventional webhooks. ml-connector polls PeopleSoft on a conservative schedule, usually every five to fifteen minutes to protect the on-premise server, and calls Avalara synchronously so the tax result returns on the same request.

Oracle PeopleSoftAvalara

Oracle PeopleSoft and Avalara integration

Oracle PeopleSoft runs your accounts payable, procurement, and general ledger. Avalara calculates the sales and use tax that has to land on those documents. Connecting the two means a voucher or sales invoice created in PeopleSoft is sent to Avalara for a jurisdiction-accurate tax figure, and that figure comes back onto the PeopleSoft record. ml-connector handles the very different APIs on each side and moves the data on a schedule you control, because neither system pushes events.

How Oracle PeopleSoft works

Oracle PeopleSoft exposes finance data through its Integration Broker on a customer-hosted base URL and node name, using HTTP Basic Auth with an OPRID and password. Delivered REST endpoints under the eSettlements and eProcurement services are read-only inquiry calls for invoice status, payment status, and requisition status. Creating or updating vouchers, suppliers, and GL journals is done through SOAP Component Interfaces such as AP_VOUCHER, VENDOR_CI, and JOURNAL_ENTRY_CI. PeopleSoft has no real webhooks, so the connector reads on a schedule unless an admin configures Integration Broker async routing to push XML.

How Avalara works

Avalara exposes its AvaTax REST v2 API at a fixed cloud base URL, authenticated with HTTP Basic Auth built from a numeric account ID and a license key. The central object is the transaction, created with POST to the transactions endpoint as a SalesInvoice, PurchaseInvoice, ReturnInvoice, or order type, with line items, ship-from and ship-to addresses, and tax codes. The call is synchronous and returns the calculated tax inline. Avalara holds no vendors, purchase orders, or GL accounts; those are passed as string codes on the transaction. Avalara sends no webhooks, so status is read by polling.

What moves between them

The main flow runs from Oracle PeopleSoft into Avalara. ml-connector reads new AP vouchers and sales documents from PeopleSoft and posts each one to Avalara as a PurchaseInvoice or SalesInvoice transaction, carrying the line amounts, addresses, and tax codes Avalara needs to determine tax. The calculated tax amount returns inline and ml-connector writes it back onto the PeopleSoft voucher through the AP_VOUCHER Component Interface. Customers and items are aligned into Avalara so exemption certificates and tax codes resolve correctly. Polling cadence is configurable, typically every five to fifteen minutes to respect the on-premise server.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the PeopleSoft side it accepts the customer base URL, Integration Broker node name, and OPRID, since PeopleSoft is self-hosted with no shared address, and it reads vouchers through delivered REST inquiry endpoints while writing the returned tax back through the AP_VOUCHER SOAP Component Interface. On the Avalara side it sends the account ID and license key as Basic Auth and posts each document with createOrAdjust, using the PeopleSoft document number as the Avalara code so a retry updates the same uncommitted transaction instead of creating a duplicate. Because both systems are pull-only, it polls PeopleSoft on a conservative interval and backs off with jitter on Avalara HTTP 429 and PeopleSoft 500 or 503 responses. Real gotchas it handles: PeopleSoft sends no signature on async pushes and returns cryptic Integration Broker error codes, while a committed Avalara transaction locks its code, so ml-connector keys on the voucher number and reconciles before re-posting.

A real-world example

A regional industrial distributor of about three hundred staff runs Oracle PeopleSoft Financials for accounts payable and procurement across several states. Before the integration, the AP team keyed vendor invoices into PeopleSoft and then manually looked up use tax for each shipping destination, which was slow and produced under-accrued tax that surfaced in audits. With Oracle PeopleSoft and Avalara connected, every voucher is posted to Avalara as a PurchaseInvoice the moment it is entered, the correct self-assessed use tax comes back onto the voucher, and the manual lookup and the audit exposure both disappear.

What you can do

Post Oracle PeopleSoft AP vouchers to Avalara as PurchaseInvoice transactions and write the self-assessed use tax back onto the voucher.
Send PeopleSoft sales documents to Avalara as SalesInvoice transactions for jurisdiction-accurate sales tax.
Align PeopleSoft customers and items into Avalara so exemption certificates and tax codes resolve correctly.
Bridge PeopleSoft OPRID Basic Auth with Avalara account ID and license-key authentication.
Use each PeopleSoft document number as the Avalara code with createOrAdjust so retries never double-post tax.

Questions

Which direction does data move between Oracle PeopleSoft and Avalara?: The main flow is Oracle PeopleSoft into Avalara. Vouchers and sales documents move from PeopleSoft to Avalara for tax calculation, and the calculated tax returns and is written back onto the PeopleSoft voucher. Avalara holds no vendor, purchase order, or GL records, so nothing accounting-related is mastered there.
How does the integration avoid posting the same transaction to Avalara twice?: Avalara uses the document code on a transaction as its idempotency key. ml-connector sends each PeopleSoft document number as that code and posts with createOrAdjust, so a retry updates the same uncommitted transaction instead of creating a duplicate. Once a transaction is committed its code is reserved, so ml-connector reconciles by document number before any re-post.
Do I need webhooks on either side for this to work?: No. Neither system pushes events: Avalara has no outbound callbacks and PeopleSoft has no conventional webhooks. ml-connector polls PeopleSoft on a conservative schedule, usually every five to fifteen minutes to protect the on-premise server, and calls Avalara synchronously so the tax result returns on the same request.

Connect Oracle PeopleSoft and Avalara

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started