Microsoft Dynamics GP and Square integration

What moves between them

Square orders and payments flow into Microsoft Dynamics GP. When a Square order is created, ml-connector reads it and creates a corresponding receivables (AR) invoice in GP, mapping the Square customer to a GP customer record and the order line items to GP GL accounts and inventory items. When Square payment is received, ml-connector posts a cash receipt in GP's bank reconciliation module, allocating it to the AR invoice. Reference data such as customers and GL accounts are read from GP and cached so that every order and payment maps to valid GP dimensions. GL postings in GP flow the opposite direction if needed, but typically ar transactions in GP are read-only from the perspective of this integration.

How ml-connector handles it

ml-connector stores Square OAuth2 credentials encrypted and refreshes the token on every 30-day expiry. On the GP side, it accepts the full on-premises endpoint URL, port, and company database name from the customer, and it presents Windows domain credentials (provided by the customer as an Active Directory service account) on every SOAP or SBA request using Negotiate or NTLM challenge-response. It can subscribe to Square webhooks for real-time payment and order notifications, or poll both systems on a schedule you define if webhooks are not available at your Square location. Before posting an AR invoice or cash receipt in GP, ml-connector queries GP to validate that the customer exists and that the GL accounts mapped from Square order lines are open and accessible. If an AR invoice creation fails in GP (e.g., due to closed fiscal period or missing GL account), ml-connector retries with exponential backoff and logs the error, and the order record is audited so you can replay it once the GP condition is resolved. Square rate limits return HTTP 429 and ml-connector respects backoff headers. GP has no published rate limits but aggressive polling can degrade on-premises performance, so defaults are set conservatively.

A real-world example

A regional retailer operates a chain of physical stores with a central headquarters running Microsoft Dynamics GP for accounting, payables, and inventory control. The stores use Square for point-of-sale transactions. Before the integration, the accounting team exported Square settlement reports daily and manually entered each store's sales and payments into GP by hand, re-keying customer names, amounts, and cost allocations. Month-end close required reconciling total payments across all stores to the bank deposit records. With Square and GP connected, each Square order posts as an AR invoice in the correct customer record, and each payment posts as a cash receipt allocated to the matching invoice, all without re-keying. Reconciliation is now automated and the monthly close closes a week earlier.

What you can do

• •Sync Square orders into Microsoft Dynamics GP as receivables invoices, mapped to the correct customer and GL accounts.
• •Post Square payments as cash receipts in GP, allocated to the corresponding AR invoice.
• •Authenticate Square via OAuth2 and refresh tokens on a 30-day cycle, and GP via Windows domain credentials over SOAP or SBA REST.
• •Subscribe to Square webhooks for real-time order and payment events, or poll both systems on a schedule tied to your settlement cycle.
• •Validate GL accounts and customers in GP before posting, with automatic retries and a full audit trail on every transaction.

Questions

How does ml-connector bridge Square's OAuth2 to Microsoft Dynamics GP's Windows Authentication?

ml-connector stores Square OAuth2 credentials encrypted and refreshes the access token automatically every 30 days. For GP, it accepts a Windows domain service account from the customer (created in Active Directory) and presents those credentials on every SBA REST or SOAP request using Negotiate or NTLM challenge-response. The two auth schemes are completely independent and managed separately, allowing a single ml-connector instance to speak both protocols.

Which way does data flow between Square and Microsoft Dynamics GP?

The primary flow is Square to GP. Square orders become AR invoices in GP and Square payments become cash receipts. GL postings in GP are read by ml-connector for validation purposes but are not written back to Square, since Square is a commerce layer without a chart of accounts. Reference data such as customers and GL accounts are read from GP to ensure all Square transactions map to valid GP dimensions.

What happens if an order or payment fails to post in GP?

ml-connector logs the error with full context, captures the Square order or payment record as an unposted audit entry, and retries with exponential backoff. You can view failed records in the audit dashboard, resolve the underlying GP condition (e.g., reopen a closed fiscal period), and replay the record. Every transaction carries a deduplication key so replays do not create duplicates in GP.