Sync Wingspan to Oracle E-Business Suite

You write the middleware that reads activity from Wingspan and stages it for Oracle E-Business Suite (EBS). The sync only reads from Wingspan. It records in EBS what already happened in Wingspan, and it never moves money.

EBS predates REST APIs as a design concept. Where Oracle Fusion Cloud has native REST resources you call directly, EBS's integration model, unchanged since the 1990s, is: stage rows in an interface table, run a concurrent program (a scheduled batch job) to validate and import them, then read the application tables back out. Every modern option for EBS, including its REST wrapper, is built on that same pattern. Plan for batch latency, not a synchronous request-response cycle.

Where Wingspan fits

• Wingspan onboards your contractors, collects card and ACH payments from your clients, records checks and wires paid outside Wingspan, pays contractors, and files 1099s.
• EBS Payables (AP) books what you owe contractors. EBS Receivables (AR) books what your clients owe you.

Data flows one way, from Wingspan to EBS. EBS stays the book of record, and Wingspan stays the record of every payment.

How the sync works

sequenceDiagram
  participant WS as Wingspan
  participant Sync as Your sync
  participant EBS as E-Business Suite
  WS->>Sync: Webhook (Payable.Paid), or your 15-minute sweep
  Sync->>WS: GET /v3/payments/payables/{id}?expand=payee
  Sync->>EBS: Stage AP_INVOICES_INTERFACE + AP_INVOICE_LINES_INTERFACE rows
  Sync->>EBS: Submit Payables Open Interface Import (Source = your SOURCE value)
  Sync->>Sync: Poll FND_CONCURRENT_REQUESTS, or wait for the Business Event
  Sync->>EBS: Read back AP_INVOICES_ALL once imported; write the Wingspan payment per your controller's chosen method
  Note over Sync,EBS: Every 15 minutes: Wingspan event log from the cursor, then an EBS status poll

Wingspan pushes Payable.Paid and Invoice.Opened events to your webhook, with a 15-minute sweep of the event log and a search-row poll as a backstop, the same as the Fusion Cloud guide. The difference is entirely on the EBS side: nothing you stage in an interface table is live until the concurrent program that processes it runs, on its own schedule or by your own trigger.

Set up EBS first

Do this with your Oracle apps team before the first sync.

• Confirm which supplier module the client runs. AP_SUPPLIERS_INT, AP_SUPPLIER_SITES_INT, and AP_SUP_SITE_CONTACT_INT are core Payables interface tables; every EBS Payables customer has them, loaded by the three classic Open Interface Import programs. Supplier Hub / Supplier Lifecycle Management is a separately licensed module that reuses those same tables through a different program, Integrated Supplier Import, and adds its own bank-account tables (POS_BANK_ACCOUNT_DET_INT/POS_BANK_ACCNT_OWNERS_INT). If the client doesn't have Supplier Hub, use the classic programs and IBY_EXT_BANKACCT_PUB for bank accounts instead.
• Confirm ISG patch level, if you'll call anything over REST. Integrated SOA Gateway (ISG) can expose Open Interface tables as REST CRUD resources since a 2018 consolidated patch (27949145 on 12.2, 27941624 on 12.1.3). ISG REST runs natively; ISG SOAP needs Oracle SOA Suite, licensed separately. A client still on 12.1 may be past Premier Support, which can turn "apply the patch" into its own project.
• Confirm the SOURCE lookup value your sync will use on AP_INVOICES_INTERFACE, exactly as configured in Payables Lookups. A case or whitespace mismatch is the most common reason rows sit in the interface table unprocessed.
• Confirm Multi-Org Access Control (MOAC). ORG_ID has to be correct on every interface row, and a multi-entity client may need the import run once per operating unit.
• Agree on a completion signal. Every concurrent program can raise oracle.apps.fnd.concurrent.request.completed as a Business Event (configured on the program's Business Events tab), consumable by your sync. Polling FND_CONCURRENT_REQUESTS by request ID is the simpler default if the client doesn't want to configure that.
• Agree on how Wingspan's AP payment gets recorded. There's no public write API for recording an external payment against an EBS invoice; the manual payment form, or an internal package, are the only options. For most EBS clients, the more realistic pattern is the opposite direction: EBS's own Payment Process Request disburses, and Wingspan acts as a payment-file destination instead of a payer. Settle this with the client before building either direction.
• 1099 ownership and withholding. If Wingspan files the 1099, set FEDERAL_REPORTABLE_FLAG to N on the supplier record so EBS's own 1099 process doesn't also file. AP_INVOICES_INTERFACE.LINE_TYPE_LOOKUP_CODE rejects AWT outright; withholding is configured elsewhere in EBS Payables if it's in scope.

Map your objects

Onboarding: stage the supplier

Stage one row per table, keyed together by INVOICE_ID-style generated IDs specific to each interface:

-- Core Payables (no Supplier Hub)
AP_SUPPLIERS_INT:        VENDOR_INTERFACE_ID, VENDOR_NAME, TAX payer fields, ...
AP_SUPPLIER_SITES_INT:   VENDOR_SITE_INTERFACE_ID, VENDOR_SITE_CODE, ADDRESS_LINE1..COUNTRY, PAY_SITE_FLAG='Y'
AP_SUP_SITE_CONTACT_INT: VENDOR_CONTACT_INTERFACE_ID, FIRST_NAME, LAST_NAME, EMAIL_ADDRESS

-- Then run
Supplier Open Interface Import
Supplier Sites Open Interface Import
Supplier Site Contacts Open Interface Import

The site row carries its own address, so there's nothing to stage before it. PAY_SITE_FLAG = 'Y' is what makes the site invoiceable; a supplier with no pay site rejects every invoice against it.

If the client has Supplier Hub, stage the same three tables plus SDH_BATCH_ID and PARTY_ORIG_SYSTEM_REFERENCE (your Wingspan payee ID), and run Integrated Supplier Import instead, which pre-processes into the TCA staging tables for you.

Payables

On Payable.Paid:

AP_INVOICES_INTERFACE:
  INVOICE_ID (generated), INVOICE_NUM = <payable ID>, INVOICE_AMOUNT, INVOICE_DATE,
  VENDOR_NUM = <your supplier number>, SOURCE = 'WINGSPAN'

AP_INVOICE_LINES_INTERFACE:
  INVOICE_ID (same as header), LINE_NUMBER, LINE_TYPE_LOOKUP_CODE = 'ITEM', AMOUNT, DIST_CODE_CONCATENATED

-- Submit
Payables Open Interface Import  (Source = 'WINGSPAN', Group = <optional batch name>)

INVOICE_AMOUNT must equal the sum of the line amounts, or the whole invoice is rejected. SOURCE must match the lookup value exactly, case and whitespace included. The import doesn't run Invoice Validation, approval, or accounting; those are separate steps scheduled after import.

Reading the result back means querying base tables, since there's no seeded status API:

As noted above, there's no public API to write an external payment back onto this invoice. If your controller wants the invoice to show paid, that has to run through EBS's own manual payment entry or an internal package your apps team approves; confirm this before promising a write-back in either direction.

Receivables

On Invoice.Opened, stage AutoInvoice:

RA_INTERFACE_LINES_ALL:         header + line data, Transaction Flexfield = <your invoice ID>
RA_INTERFACE_DISTRIBUTIONS_ALL: ACCOUNT_CLASS in (REV, FREIGHT, TAX, REC, CHARGES, UNBILL, UNEARN)

-- Submit
AutoInvoice Master Program, then AutoInvoice Import Program

If ISG is patched for Open Interface REST exposure, you can write these rows over HTTP instead of a DB link or SQL*Loader, using Oracle's own documented pattern:

curl -X POST "https://your-ebs-host/webservices/rest/autoinvoice/RA_INTERFACE_LINES_ALL/" \
  -u "$EBS_USER:$EBS_PASSWORD" \
  -H "Content-Type: application/json" \
  -d '{ "RESTHeader": { "Responsibility": "...", "Application": "...", "SecurityGroup": "...", "Language": "AMERICAN", "OrgId": "204" }, "InputParameters": { ... } }'

This only replaces the loading step; AutoInvoice Import still has to run afterward, on its own schedule or triggered separately.

For a synchronous, one-at-a-time alternative that skips interface tables entirely, call AR_INVOICE_API_PUB.CREATE_SINGLE_INVOICE directly (trx_header_id, bill_to_customer_id, line fields), which Oracle positions as a parallel option to AutoInvoice, not a replacement for it. Only 'Manual' batch sources are permitted through this API.

Once Wingspan collects payment, record the receipt:

-- AR_RECEIPT_API_PUB.Create_and_apply(
--   p_amount => 945.00, p_receipt_method_id => <id>, p_customer_id => <id>,
--   p_comments => 'Wingspan invoice <id>', ...
-- )

Create_and_apply creates and applies the receipt in one call and routes through Oracle Payments for card/processor flows; Create_cash plus a separate Apply call is the alternative if you need the two steps split.

Idempotency and completion

Every write in this guide resolves on the concurrent manager's own schedule, not in the call that triggers it. Default to polling FND_CONCURRENT_REQUESTS by request ID; raise the Business Event option (oracle.apps.fnd.concurrent.request.completed) with the client's apps team if polling on an interval is too slow.

A rejected invoice line or distribution rejects the entire invoice at import, so validate everything you can before staging the rows, and treat any rejection as "resubmit the whole invoice," not "patch one line." Check AP_INTERFACE_REJECTIONS (AP) or RA_INTERFACE_ERRORS_ALL (AR) for the reason.

Subscribe to Wingspan events

Use the same subscription shown in the Fusion Cloud guide. The event side is identical; only what you do with the event on the EBS side differs.

Pitfalls

1. Core Payables and Supplier Hub share interface tables but not the processing program. Pointing a client's apps team at POS_BANK_ACCOUNT_DET_INT when they only have core Payables wastes a build cycle; confirm the module first.
2. HZ_CUST_ACCOUNT_V2PUB and HZ_CUST_ACCOUNT_SITE_V2PUB are different packages. The account comes from the first; the account site and bill-to site use come from the second.
3. TCA Bulk Import is party-level only in EBS. For account/site/use data, use Customer Interface or the HZ_*_V2PUB APIs; the Fusion Cloud HZ_IMP_ACCOUNTS_INT-style tables don't exist in EBS.
4. A problem on any one AP line or distribution rejects the whole invoice.
5. SOURCE must match a configured lookup value exactly, case and whitespace included.
6. MOAC: ORG_ID is required on every row, and a multi-org client may need one import run per operating unit.
7. No public API writes an external payment onto an EBS AP invoice. Confirm with the client's apps team how (or whether) that happens before promising it.
8. No native completion push from a concurrent program, unless the client configures the Business Event. Default to polling.
9. ISG's REST-for-interface-tables feature needs a specific patch, not just "ISG is installed": 27949145 on 12.2, 27941624 on 12.1.3.
10. ISG SOAP needs Oracle SOA Suite, licensed separately; ISG REST does not.
11. A supplier needs a pay site (PAY_SITE_FLAG = 'Y') to be invoiced.
12. AWT is rejected as an AP line type. Withholding is configured elsewhere in EBS Payables.

Before you go live

1. Agree the mapping with the client's apps team: which supplier module they run, the SOURCE and Group values, MOAC setup, who owns 1099 filing and withholding, and which direction AP payments flow.
2. Confirm ISG patch level and auth mode if any part of the sync calls EBS over REST.
3. Run one supplier, one payable, and one invoice end to end in a test instance, including a deliberately bad line to confirm the whole-invoice rejection behavior.
4. Agree on a completion signal (poll or Business Event) and build your sync log around it before going live.

Related pages

• Sync Wingspan to Oracle Fusion Cloud ERP
• Webhooks and events
• Webhook event types
• Components of a payable
• Components of an invoice
• Oracle: Integrated SOA Gateway Developer's Guide, Payables Reference Guide