Sage Intacct and Snowflake integration

What moves between them

The main flow runs from Sage Intacct into Snowflake. Vendor masters, AP bills, AP payments, and GL account references flow one direction: ml-connector polls Intacct on a schedule, transforms the XML records into JSON, and inserts them into Snowflake tables. GL posting dimensions (cost centers, departments) are read from Intacct and upserted into Snowflake lookup tables so downstream queries can join on them. Snowflake is read-only for this integration; no data flows back to Intacct. The cadence is scheduler-driven, typically daily or on-demand after period close.

How ml-connector handles it

ml-connector stores the Intacct senderId, senderPassword, companyId, userId, and userPassword encrypted, and caches the resulting sessionid for up to 50 minutes. Before each cache miss, it re-authenticates via getAPISession. The connector polls the XML gateway for updated records by sending batch read requests with uniqueid flags for server-side deduplication. Because HTTP 200 from Intacct may wrap application errors inside the XML body, ml-connector parses every response for errormessage tags and status codes before treating it as success. Forbidden XML control characters (C0 controls except tab, newline, carriage return) are stripped before entity escaping. On the Snowflake side, ml-connector connects with a key-pair authentication token and executes SQL INSERT or UPSERT statements against user-defined tables. Async queries are polled via the statementHandle until completion. Retries use exponential backoff; Snowflake's HTTP 429 is handled with backoff and jitter. The connector tracks the last successful sync timestamp and filters Intacct queries by updated records only.

A real-world example

A mid-market distribution company runs Sage Intacct for general ledger, AP, and vendor master data across four regional warehouses. The finance team needs to analyze vendor spend trends, invoice aging, and payment patterns to optimize cash flow and supplier contracts. Before the integration, they exported vendor and invoice data from Intacct monthly, re-imported it into spreadsheets, and lost the ability to drill into historical records or detect payment anomalies. With Sage Intacct and Snowflake connected, vendor masters and AP invoices flow automatically into Snowflake tables every night. The finance team runs SQL queries on invoice aging, payment reconciliation, and vendor KPIs without manual export-import. They set up a Snowflake dashboard that refreshes daily, showing current payables, aging buckets, and variance reports that feed month-end close meetings.

What you can do

• •Stream Sage Intacct vendors, AP bills, and AP payments into Snowflake tables on a polling schedule.
• •Parse XML responses from Intacct's gateway and validate for application-level errors before loading.
• •Manage Intacct session authentication with automatic refresh before cache expiry at 50 minutes.
• •Map Intacct GL accounts and dimensions to Snowflake lookup tables for reporting joins and analysis.
• •Use timestamp watermarks to detect and sync only updated records from Intacct on each run.

Questions

Why does ml-connector poll instead of subscribe to Intacct webhooks?

Sage Intacct does not offer native webhook push for cloud connectors. ml-connector polls the XML gateway on a schedule that matches your close calendar or run frequency. Session credentials are cached for 50 minutes and refreshed automatically, so polling overhead is minimal.

How does ml-connector handle Intacct's XML response errors?

HTTP 200 from Intacct can wrap application-level errors inside the XML body as errormessage tags and status codes. ml-connector parses every response for these markers before treating the call as successful. Forbidden XML control characters are stripped before escaping, so data integrity is preserved.

Which authentication method should I use for Snowflake: key-pair or access token?

Key-pair authentication with RSA private key and JWT is recommended for server-to-server integration like this one, as it avoids long-lived bearer token exposure. Programmatic access tokens are supported but expire (15 days by default, up to 1 year), so rotation must be managed.