QAD and Tipalti integration
QAD runs manufacturing, procurement, and finance. Tipalti runs accounts payable automation and global supplier payments. Connecting the two lets approved supplier invoices in QAD become payable bills in Tipalti, and lets Tipalti pay suppliers across many countries and currencies without finance re-keying anything. Payment status and payee records flow back so QAD's ledger reflects what Tipalti actually paid. ml-connector handles the different auth and transport on each side and keeps suppliers and GL accounts aligned.
What moves between them
The main flow runs from QAD into Tipalti. Approved supplier invoices in QAD, with their line items, amounts, currency, due dates, and GL account codes, are created in Tipalti using CreateOrUpdateInvoices so they enter the payment queue. Suppliers map to Tipalti payees, and goods receipts can move across to support three-way match before an invoice is paid. The return flow runs from Tipalti into QAD: payment results from GetUpdatedPayments and payment IPN events post settlement status back to QAD's AP, and payee detail changes keep supplier records current. GL accounts and tax codes are aligned in both directions so every bill references a code that exists on each side.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and reads using the JWT or OAuth2 bearer token. On the Tipalti side it computes the HMAC-SHA256 signature from the exact payer name, timestamp, and API key on every SOAP call, and uses OAuth2 or x-api-key for REST endpoints. Because QAD cloud is pull-only, it polls QAD on a schedule for newly approved invoices and receipts rather than waiting for a push, and it receives Tipalti payment status through IPN callbacks whose signature it recomputes and verifies. Suppliers and GL accounts are mapped first so each invoice lands on a valid payee and account. Upserts are naturally idempotent, so re-sending the same invoice updates rather than duplicates, and Procurement REST rate limits (PO updates limited to a few per minute, PO reads roughly every ten minutes) are respected with backoff. Two edge cases matter: the payer name must match exactly or the signature fails silently, and updating a payee address forces the payee to re-confirm their payment method. Every record carries a full audit trail and can be replayed if a downstream call fails.
A real-world example
A mid-sized consumer electronics manufacturer runs QAD Adaptive ERP for production, procurement, and AP, and pays several hundred component suppliers across North America, Europe, and Asia. Before the integration, the finance team approved supplier invoices in QAD, then manually built payment files and chased currency and banking details for overseas vendors, which delayed payments and created reconciliation work at close. With QAD and Tipalti connected, approved invoices flow into Tipalti automatically, Tipalti handles the cross-border payment rails and tax compliance, and settled payment status posts back into QAD. Suppliers are paid on time in local currency, and the AP ledger reconciles to actual payments without a separate file step.
What you can do
- Create approved QAD supplier invoices as payable bills in Tipalti for global, multi-currency payment.
- Map QAD suppliers to Tipalti payees and align GL accounts and tax codes on both sides.
- Post Tipalti payment results and IPN settlement events back into QAD's accounts payable.
- Bridge QAD tenant login with Tipalti HMAC-SHA256 signing and OAuth2 or x-api-key REST auth.
- Poll QAD on a schedule with idempotent upserts, rate-limit backoff, retries, and a full audit trail.
Questions
- Which direction does data move between QAD and Tipalti?
- The main flow is QAD into Tipalti: approved supplier invoices and the suppliers behind them move from QAD into Tipalti for payment. The return flow is Tipalti into QAD, carrying payment status and payee detail changes. GL accounts and tax codes are aligned in both directions so every bill references a valid code on each side.
- How does ml-connector handle Tipalti's different APIs and authentication?
- Tipalti splits into a SOAP API that signs each call with an HMAC-SHA256 hash of the payer name, timestamp, and API key, and a REST API that uses OAuth2 or a static x-api-key for the Procurement module. ml-connector computes the correct signature or token per endpoint and stores both credential sets encrypted. It also verifies the HMAC signature on inbound IPN webhook events before acting on them.
- How are payments and settlement status kept in sync given QAD has no webhooks?
- Because QAD cloud is pull-only, ml-connector polls QAD on a schedule for newly approved invoices and goods receipts rather than relying on a push. Tipalti sends payment status the other way through IPN callbacks and the GetUpdatedPayments read, which ml-connector posts back into QAD's accounts payable. Upserts are idempotent, so a retried or repeated invoice updates the existing record instead of creating a duplicate.
Related integrations
More QAD integrations
Other systems that connect to Tipalti
Connect QAD and Tipalti
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started