Sage Intacct and Square integration

What moves between them

Invoices created in Square flow into Sage Intacct as AP bills mapped to Intacct vendors and GL accounts. Payments received via Square update the AP payment status in Intacct. Reference data such as vendors and GL mappings are maintained in both directions so Square invoices land on valid Intacct chart accounts. Data flows on a polling schedule or at the cadence of Square webhook events if enabled. Intacct GL posting is authoritative; Square is the payments source.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Intacct side, it caches the 50-minute session to avoid repeated getAPISession calls, and automatically refreshes it before expiry by re-authenticating with the stored partner and user credentials. Square access tokens are cached and refreshed using the refresh token when the 30-day window approaches, with no extra re-authentication required if the non-expiring refresh token is provided. All Intacct operations serialize through the single XML gateway, so ml-connector batches requests and parses XML responses for application-level errors inside the body. Square does not expose a native GL Accounts API, so invoice-to-GL mapping is driven by customer-supplied vendor-to-GL rules stored as a mapping table in ml-connector. Square vendor records are read from the beta Vendors API and may be incomplete; Intacct vendors remain the system of record. HTTP 429 rate limits on either side trigger exponential backoff and retry. Every record carries a full audit trail.

A real-world example

A mid-sized services firm uses Square for invoicing and payment processing across multiple locations and Sage Intacct for consolidated accounting and GL reporting. Before integration, the finance team exported Square payment records weekly and manually entered them into Intacct as AP payments, then reconciled vendor balances by hand. With the two connected, each Square invoice automatically creates an AP bill in Intacct mapped to the correct vendor and GL account, and payments flow in without re-keying. Month-end close is faster because the AP ledger and cash accounts are already synchronized.

What you can do

• •Sync Square invoices into Sage Intacct as AP bills, mapped to vendors and GL accounts.
• •Reflect Square payments in Intacct AP payment status so cash and payables stay aligned.
• •Cache Intacct sessions to avoid re-authentication on every call and refresh Square access tokens before expiry.
• •Parse Intacct XML responses for application-level errors and handle rate limits on both sides with exponential backoff.
• •Maintain a full audit trail on every record so failed syncs can be investigated and replayed.

Questions

How does the integration handle Sage Intacct's session timeout and Square's token expiry?

ml-connector caches the Intacct session for its full 50-minute lifetime and automatically refreshes it with the stored credentials before expiry on the next call. Square access tokens are refreshed 5 days before the 30-day window closes using the non-expiring refresh token. No manual re-authentication is needed for either system.

Sage Intacct has no GL Accounts API and Square is payments-only. How does the integration map invoices to GL?

ml-connector uses a customer-supplied vendor-to-GL mapping table to post invoices on the correct GL accounts when they are imported from Square. Intacct vendors remain the system of record. If a Square vendor does not match an Intacct vendor, the record is flagged in the audit log and the sync is paused pending vendor alignment.

What if a Square invoice or payment fails to post into Intacct?

ml-connector stores the credential sets and request/response pairs in its audit log, so a failed record can be investigated and replayed without re-downloading the original data. If a rate limit is hit, ml-connector backs off exponentially and retries automatically.