QAD and SAP Ariba integration

What moves between them

The main flow runs from SAP Ariba into QAD. ml-connector submits reporting jobs for purchase orders and invoices, downloads the results, and writes them into QAD as purchase orders and supplier invoices, the invoices landing ahead of three-way match against QAD goods receipts. Supplier profiles read from the SAP Ariba Supplier Data API keep the QAD vendor master aligned, including registration and qualification status. The cost center and GL codes carried on each Ariba PO and invoice line are mapped to the matching QAD accounts so documents post to valid dimensions. SAP Ariba has no dedicated GL API, so ml-connector does not write financial entries back into Ariba; procurement document write-back uses cXML rather than the REST APIs and stays out of scope.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On every SAP Ariba call it presents the OAuth bearer token and the static apiKey header together, refreshes the one-hour token before it expires, and appends the customer realm as a query parameter. Because purchase orders and invoices come through async jobs, it submits a reporting job filtered by an updated-date window, polls for completion, downloads the paginated results, and stores a high-water-mark timestamp so the next run only picks up changes. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. Cost centers and GL codes are mapped first so every PO and invoice line references a QAD account and cost center that already exists, and supplier matching keeps the vendor master in step. Reporting jobs enforce a one-year window, so an initial backfill is split into annual chunks. SAP Ariba rate limits are tight on job submission and surface in the X-RateLimit-Remaining-minute header, so ml-connector watches that header, backs off before a 429, and retries. Every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-sized contract manufacturer running QAD Adaptive ERP for production and finance uses SAP Ariba for sourcing and supplier-facing purchasing across several plants. Before the integration, buyers approved purchase orders and suppliers submitted invoices in SAP Ariba, then a clerk re-keyed each PO and invoice into QAD so receipts and payments could be processed, and month-end stalled while staff reconciled the two systems and chased mismatched cost centers. With QAD and SAP Ariba connected, approved POs and invoices flow into QAD on schedule, invoices arrive ready for three-way match against goods receipts, and supplier profiles stay aligned. The re-keying step is gone and procurement documents reach finance the same day they are approved.

What you can do

• •Pull SAP Ariba purchase orders into QAD through async reporting jobs, mapped to the correct cost centers.
• •Bring SAP Ariba supplier invoices into QAD as records ready for three-way match against goods receipts.
• •Keep the QAD vendor master aligned with SAP Ariba supplier profiles and their registration and qualification status.
• •Authenticate SAP Ariba with an OAuth bearer token plus the required apiKey header and realm query parameter, and QAD with its tenant-specific token.
• •Poll on a schedule with high-water-mark tracking, rate-limit-aware backoff, retries, and a full audit trail on every record.

Questions

Which direction does data move between QAD and SAP Ariba?

The main flow is SAP Ariba into QAD. Purchase orders, supplier invoices, and supplier profiles move from SAP Ariba into QAD, with cost center and GL codes mapped to valid QAD accounts. SAP Ariba has no dedicated GL API and procurement write-back uses cXML rather than REST, so ml-connector does not post financial entries back into Ariba.

Why does the integration poll SAP Ariba instead of receiving webhooks?

SAP Ariba does not offer a general outbound webhook from its Open APIs, and purchase orders and invoices are extracted through async reporting jobs rather than a simple GET endpoint. ml-connector submits a job filtered by an updated-date window, polls until it completes, downloads the paginated results, and stores a high-water mark so each run only collects new changes. Event push exists only through the separate SAP Event Mesh service, which is outside this connector.

How does the connector handle SAP Ariba authentication and rate limits?

Every SAP Ariba call needs two credentials together, an OAuth2 bearer token and a static apiKey header, plus the customer realm as a query parameter, and the token expires after one hour. ml-connector stores the credentials encrypted, refreshes the token before it expires, and appends the realm to each request. It also reads the X-RateLimit-Remaining-minute header so it can back off before hitting a 429 and retry, since SAP does not raise these limits on request.