Oracle PeopleSoft and BILL integration

What moves between them

The main flow runs from Oracle PeopleSoft into BILL. ml-connector reads suppliers and approved AP vouchers from PeopleSoft and creates or updates them in BILL as vendors and bills, mapped to the matching BILL chart-of-accounts entries and departments. Payment results flow the other direction: BILL payment status and recorded payments are read back so PeopleSoft shows what cleared, posted through the journal Component Interface or staged for reconciliation. GL accounts, cost centers, and departments are aligned so each bill line carries a valid account. Purchase orders are not sent, because BILL has no PO object, so only the approved bills cross over and the PO stays in PeopleSoft.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the PeopleSoft side it accepts the customer-specific base URL and Integration Broker node name, since there is no shared hostname, sends Basic Auth with the OPRID and password, and uses the read-only REST inquiry endpoints for status while writing vouchers and reading journals through the Component Interface SOAP services. On the BILL side it logs in once with the developer key, organization id, and credentials to get a session token, then refreshes that token whenever a call returns 401, because the 35-minute session expiry is silent. GL accounts, cost centers, and departments are mapped first so every bill line references a BILL chart-of-accounts entry that already exists. Neither system provides idempotency keys, so ml-connector dedupes on the PeopleSoft voucher and supplier identifiers and a BullMQ job id before it creates a bill or vendor, which avoids double-booking a re-read record. Because PeopleSoft is pull-only over Integration Broker, it polls suppliers and vouchers on a conservative interval with backoff on 500 and 503 errors, and it verifies BILL payment webhooks with the x-bill-sha-signature HMAC before treating a push as the trigger to post settlement back. BILL allows only three concurrent calls per org, so it limits in-flight requests and backs off on the BDC_1322 and BDC_1144 rate-limit codes. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized professional services firm with about 600 employees runs Oracle PeopleSoft for procurement, accounts payable, and the general ledger, and adopts BILL so approvers can review and pay vendor invoices from their phones. Before the integration, the AP team exported approved vouchers from PeopleSoft and re-keyed them into BILL, then typed payment confirmations back into PeopleSoft by hand, which left the ledger a day or two behind and produced mismatches at month-end. With Oracle PeopleSoft and BILL connected, each approved voucher becomes a BILL bill against the right vendor and GL account automatically, and the moment a payment clears in BILL the status flows back into PeopleSoft. The duplicate entry is gone and the AP accounts reconcile without a manual catch-up.

What you can do

• •Create and update BILL vendors and bills from Oracle PeopleSoft suppliers and approved AP vouchers.
• •Read BILL payment status back into Oracle PeopleSoft so the ledger reflects what actually cleared.
• •Map PeopleSoft GL accounts and cost centers to BILL chart-of-accounts and departments so each bill line is valid.
• •Bridge PeopleSoft Basic Auth with BILL session-token login, refreshing the 35-minute session on a 401.
• •Poll PeopleSoft on a conservative schedule and verify BILL payment webhooks, with dedup, retries, and a full audit trail.

Questions

Which direction does data move between Oracle PeopleSoft and BILL?

The main flow is Oracle PeopleSoft into BILL. Suppliers and approved AP vouchers move from PeopleSoft into BILL as vendors and bills, while BILL payment status flows back so PeopleSoft shows what cleared. Purchase orders are not sent, because BILL has no PO object and expects POs to stay in the ERP.

How does the integration bridge the two different auth models?

PeopleSoft uses HTTP Basic Auth with an OPRID and password against the customer's own URL and node name, while BILL uses a session token returned by a developer-key login. ml-connector stores both credential sets encrypted, sends Basic Auth on PeopleSoft calls, and logs in to BILL to obtain a session token. Because the BILL session expires after 35 minutes of inactivity and fails silently, it re-logs in and retries whenever a call returns a 401.

Does Oracle PeopleSoft push changes, or does ml-connector poll for them?

ml-connector polls. PeopleSoft has no conventional webhooks, only Integration Broker asynchronous publish that a customer admin must configure, so for a connector it is effectively pull-only. It reads suppliers and vouchers on a conservative interval with backoff on server errors. BILL, by contrast, sends HMAC-signed payment webhooks, which ml-connector verifies and uses as the trigger to post settlement back into PeopleSoft.