QAD and Square integration

What moves between them

The main flow runs from Square into QAD. ml-connector reads settled Square payments and daily payouts and posts them into QAD as cash receipts and ledger entries, mapped by Square location to the matching QAD cost center and GL account. Square customers flow into QAD customer records, and Square vendors flow into QAD suppliers. Square invoices are read for revenue and outstanding balances. In the other direction, QAD items can be pushed to the Square catalog so product data stays consistent. Square holds no GL accounts, so ml-connector never expects a chart of accounts from Square and never writes journals back to Square.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Square side it sends the bearer token and the Square-Version header on every call, and because Square access tokens expire after 30 days it refreshes proactively with the refresh token rather than waiting for a 401. 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. Square locations are mapped to QAD cost centers first, so every payment and payout posts to a GL account and cost center that already exists in QAD. Payouts are reconciled against their underlying payments so a QAD cash receipt matches the bank deposit, and refunds reverse the original receipt. ml-connector can subscribe to Square webhooks for near-real-time payment and invoice events, verifying the HMAC-SHA-256 signature and returning 403 on failure, while still polling on a schedule as the source of truth because QAD cloud is pull-only. Square cursor pagination expires after five minutes, so each list is walked in one pass, and create calls carry an idempotency_key so a retry never duplicates a record. Square rate limits return HTTP 429, so ml-connector backs off with jitter and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized specialty food manufacturer runs QAD Adaptive ERP for production, procurement, and finance, and sells direct through a Square-powered factory store and online checkout across three locations. Before the integration, the accounting team downloaded Square payout reports each morning and keyed the deposit and fee totals into QAD by hand, then spent days at month-end reconciling card settlements against the bank and splitting revenue across the three sites. With QAD and Square connected, settled payments and daily payouts flow into QAD as cash receipts allocated to each location's cost center, and Square customers land in QAD without re-entry. The bank reconciliation starts already matched, and the manual export step is gone.

What you can do

• •Post settled Square payments and daily payouts into QAD as cash receipts and ledger entries, allocated to the correct cost centers.
• •Map each Square location to a QAD GL account and cost center so commerce takings land on valid accounts.
• •Bring Square customers into QAD customers and Square vendors into QAD suppliers, and push QAD items to the Square catalog.
• •Reconcile each Square payout against its underlying payments and reverse refunds so QAD matches the bank.
• •Authenticate Square with OAuth 2.0 and proactive token refresh and QAD with its tenant-specific token, with retries and a full audit trail.

Questions

Which direction does data move between QAD and Square?

The main flow is Square into QAD. Payments, payouts, invoices, customers, and vendors move from Square into QAD as cash receipts, customer records, and supplier records. QAD items can be pushed out to the Square catalog, but Square has no general ledger, so ml-connector never writes journals back into Square.

How does the integration handle accounting when Square has no GL accounts?

Square is a commerce and payments layer with no chart of accounts or GL dimensions. ml-connector maps each Square location, and optionally each payment category, to a QAD GL account and cost center in connector logic. That mapping is set up first, so every payment and payout posts to a QAD account that already exists.

Does Square use webhooks or polling, and how does that fit QAD?

Square supports HMAC-SHA-256 signed webhooks for events such as payment, invoice, and customer changes, and ml-connector can subscribe to them for near-real-time updates while returning 403 on a bad signature. Because QAD cloud is pull-only and has no webhook system, ml-connector still polls Square on a schedule as the source of truth, and reconciles each payout batch against its underlying payments before posting to QAD.