QAD and Deel integration

What moves between them

The main flow runs from Deel into QAD. After each pay cycle, ml-connector reads Deel billing and contractor invoices and posts them into QAD as supplier invoices and general ledger entries, mapped to the matching QAD GL accounts and cost centers. People and contract records flow the same direction so QAD headcount reflects Deel hires, contract changes, and terminations. Cost center references read from each Deel contract are aligned to QAD dimensions so workforce cost lands on valid accounts. Deel invoice and payment data is read-only on the QAD side of the flow, so ml-connector never writes financial entries back into Deel.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Deel side it sends the organization Bearer token on every call, and where OAuth2 is used it adds the required x-client-id header and refreshes the 30-day access token before expiry, rotating the single-use refresh token each time. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. Because QAD cloud is pull-only and exposes no GL endpoint in Deel, it polls Deel invoices, contracts, and people on a schedule rather than waiting for a push, and reads GL and cost center references from the invoice and contract payloads. It can also receive Deel webhook events where they are enabled, verifying the HMAC-SHA256 signature against the raw request body first. Cost centers are mapped before any posting, so every invoice line references a QAD account that already exists. Writes to QAD use an idempotency key so a retried post is not duplicated, Deel rate limits return HTTP 429 with a Retry-After header so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized engineering firm of about 300 staff runs QAD Adaptive ERP for projects, procurement, and finance, and uses Deel to engage contractors and remote employees across a dozen countries. Before the integration, the finance team downloaded contractor invoices and Deel fee statements every month and re-entered the totals into QAD accounts payable by hand, then reconciled headcount between Deel and the ledger during close. With QAD and Deel connected, each cycle's invoices post into QAD as supplier invoices allocated to the right cost center, and worker changes keep the two systems aligned. Close starts with global workforce cost already in the ledger, and the manual re-keying step is gone.

What you can do

• •Post Deel billing and contractor invoices into QAD as supplier invoices and GL entries each pay cycle, allocated to the correct cost centers.
• •Keep QAD headcount aligned with Deel hires, contract changes, and terminations.
• •Map Deel contract cost center allocations to QAD GL dimensions so workforce cost lands on valid accounts.
• •Authenticate Deel with an organization Bearer token or OAuth2 with its required x-client-id header, and QAD with its tenant-specific token.
• •Poll Deel on a schedule you control, with idempotent writes to QAD, retries on rate limits, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Deel?

The main flow is Deel into QAD. Billing and contractor invoices, people, and contract records move from Deel into QAD, while cost centers are aligned so workforce cost lands on valid QAD accounts. Deel invoice and payment data is read-only in this flow, so ml-connector does not write financial entries back into Deel.

Deel has no general ledger account endpoint, so how does GL mapping work?

GL accounts are not a standalone entity in Deel. Account references are embedded inside the invoice and payment payloads, so ml-connector reads them from those records and maps each line to the matching QAD GL account and cost center. Cost centers are mapped before any posting so every QAD invoice line references an account that already exists.

How does the integration handle Deel tokens and QAD's tenant-specific URL?

ml-connector sends the Deel organization Bearer token on each call, or for OAuth2 adds the required x-client-id header and refreshes the 30-day access token before it expires, rotating the single-use refresh token each time. On the QAD side it accepts the full tenant instance URL per customer, since QAD publishes no shared base address. Because QAD cloud is pull-only, it polls Deel on a schedule rather than relying on a push.