QAD and GoCardless integration
QAD runs manufacturing, sales, and finance. GoCardless collects bank debit payments from customers and pays the settled funds out to your account. Connecting the two keeps your accounts receivable in QAD in step with what GoCardless actually collected. When a direct debit payment confirms in GoCardless, the receipt is recorded against the right customer in QAD, and when a payout lands, its individual items are matched back to the bank account in the ledger. ml-connector handles the very different APIs on each side and turns GoCardless webhook events into QAD finance records.
What moves between them
The main flow runs from GoCardless into QAD. As payments move through their lifecycle, GoCardless sends webhook events, and ml-connector records each confirmed and paid out collection against the matching customer receivable in QAD. When a payout settles, its payout items are enumerated and reconciled against the bank GL account so the deposit ties out to the underlying payments, fees, refunds, and chargebacks. In the other direction, QAD customers can be pushed into GoCardless to create the customer and supporting records needed before a mandate is set up. Payouts and the event log are read-only in GoCardless, so ml-connector never writes settlement records back to the processor.
How ml-connector handles it
ml-connector stores both credential sets encrypted, sends the GoCardless Bearer access token and the GoCardless-Version header on every request, and verifies each incoming webhook by computing HMAC-SHA256 over the raw request body and comparing it to the Webhook-Signature header, returning 401 rather than 200 on a mismatch so GoCardless keeps retrying. 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. GoCardless amounts arrive as integers in the smallest currency unit, so pence and cents are converted to the decimal values QAD expects, and the currency on each payment is mapped to the matching QAD account. Because GoCardless settles in batches, payout reconciliation reads payout items, which can be archived after six months, so settlements are recorded promptly. POST calls to GoCardless carry an Idempotency-Key, and creating a payment requires an existing active mandate, so customer and mandate setup runs before any collection. Rate limit responses of 429 trigger backoff and retry, and every record carries a full audit trail and can be replayed if a downstream call fails.
A real-world example
A mid-sized subscription manufacturer ships consumable equipment to trade customers on monthly bank debit plans and runs QAD Adaptive ERP for orders, inventory, and finance. Before the integration, the finance team downloaded GoCardless payment and payout reports, then manually marked customer invoices as paid in QAD and tried to tie each lump-sum payout back to the dozens of payments inside it, which made cash application slow and left receivables open longer than they should be. With QAD and GoCardless connected, each confirmed collection is applied to the right customer automatically, and every payout is broken into its items and reconciled against the bank account. The receivables ledger reflects real collections within the day, and the payout matching step is gone.
What you can do
- Record confirmed GoCardless bank debit collections against the matching customer receivable in QAD as payment webhooks arrive.
- Reconcile each GoCardless payout against the bank GL account by enumerating its payout items, including fees, refunds, and chargebacks.
- Push QAD customers into GoCardless to create the records needed before a direct debit mandate is set up.
- Verify GoCardless webhook signatures with HMAC-SHA256 and authenticate QAD with its tenant-specific token.
- Convert GoCardless integer amounts to QAD decimal values, with retries, idempotency keys, and a full audit trail on every record.
Questions
- Which direction does data move between QAD and GoCardless?
- The main flow is GoCardless into QAD. Confirmed payments and settled payouts move from GoCardless into QAD to apply customer receipts and reconcile deposits, while QAD customers can be pushed into GoCardless to support mandate setup. Payouts and the GoCardless event log are read-only, so ml-connector does not write settlement records back to the processor.
- Does the integration poll GoCardless or use webhooks?
- It uses webhooks, which is the intended path for GoCardless. GoCardless pushes signed events, batched up to 250 per request, and ml-connector verifies the HMAC-SHA256 signature on the raw body before recording anything. Because QAD cloud has no native webhooks, ml-connector posts receipts into QAD with write calls and accepts the tenant-specific QAD URL per customer.
- How are GoCardless payouts matched to individual payments in QAD?
- GoCardless settles many payments together in one payout, so ml-connector reads the payout items for each payout to break it down into the underlying payments, fees, refunds, and chargebacks. Those items are reconciled against the bank GL account in QAD so the deposit ties out. Payout items can be archived after six months, so reconciliation runs promptly after each payout settles.
Related integrations
More QAD integrations
Other systems that connect to GoCardless
Connect QAD and GoCardless
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started