Microsoft Dynamics GP and Anaplan integration

What moves between them

The primary flow runs from Microsoft Dynamics GP into Anaplan. ml-connector polls GP for posted GL journal entries and account balances, along with cost-center segments and any vendor or employee lists the planning model needs, formats them into the file each Anaplan import action expects, and runs that import so actuals and reference lists land in the model. The return flow runs from Anaplan back into GP: once a budget or forecast is approved, ml-connector runs the Anaplan export action, downloads the result file, and creates the approved figures in GP as an unposted journal entry batch against the matching accounts. Reference data such as the chart of accounts and cost-center segments is aligned so each Anaplan list member resolves to a real GP account. Cadence follows your planning calendar, typically a nightly or period close actuals load and an export when a plan is signed off.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the GP side it authenticates with the Windows domain account using HTTP Negotiate or NTLM and pins the SBA base URL, tenant, and SQL company database name per customer, since the company name in the path is the database name and not the display name. Where SBA is not installed, it falls back to the SOAP Web Services endpoint, which exposes the same vendor, invoice, and GL operations. On the Anaplan side it requests a basic or certificate auth token, reuses it across the session, and refreshes it before the 35 minute lifetime ends rather than minting one per call, and it sends the workspace ID in lowercase hex and the model ID in uppercase hex because the wrong case returns a 404. Because Anaplan runs only actions a model builder already created, ml-connector discovers the import and export action IDs at runtime from the list endpoints rather than assuming them. Both systems are poll based, since neither pushes events: GP is read incrementally on ModifiedDate where it exists and by batch or status where it does not, while Anaplan bulk tasks are started with a POST and then polled by taskId until the state is complete, because a 200 on the POST does not mean the data is ready. Imports, exports, and writeback actions lock the Anaplan model, so ml-connector serializes tasks against the same model and never fires concurrent jobs at it. GP cost-center segments and the chart of accounts are mapped to Anaplan list members first, so every imported actual and every exported plan line lands on a member that exists. Plan figures return to GP as unposted journal batches in an open fiscal period, so a person reviews and posts them and the ledger stays authoritative. GP has no published rate limit and aggressive polling can slow the customer server, so ml-connector caps concurrency and stays inside off-hours windows, while Anaplan returns HTTP 429 against a 600 request per minute tenant ceiling, so it backs off with jitter and deduplicates work on a stable BullMQ jobId derived from the GP document number or the Anaplan task. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-market distributor with roughly 400 employees runs Microsoft Dynamics GP on its own server for finance and purchasing and builds its annual budget and rolling forecast in Anaplan. Before the integration, an analyst pulled trial balances and cost-center detail from GP through a SmartList export every month, reshaped them in a spreadsheet, and uploaded them into Anaplan by hand, then re-keyed the approved budget back into GP as a journal entry. The manual cycle took days, account and cost-center codes drifted between the two systems, and variance reports lagged the actual close. With Microsoft Dynamics GP and Anaplan connected, each period close the GL entries and cost-center segments load into the Anaplan model automatically, and when the forecast is approved the figures export back into GP as an unposted journal batch for someone to post. The analyst stops moving spreadsheets, the codes stay aligned, and variance review starts on the same numbers in both systems.

What you can do

• •Load posted Microsoft Dynamics GP GL journal entries and account balances into Anaplan planning models through named import actions.
• •Export approved Anaplan budget and forecast figures back into GP as unposted journal entry batches in an open fiscal period.
• •Map GP cost-center segments and the chart of accounts to Anaplan list members so every figure lands on a real member.
• •Bridge the GP Windows Active Directory login with Anaplan basic, certificate, or device-grant tokens.
• •Poll both systems on a schedule and serialize Anaplan's model-locking import and export tasks with retries and a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics GP and Anaplan?

Both directions. Posted GL entries, account balances, and cost-center dimensions move from GP into Anaplan through import actions to refresh the planning model, and approved budget or forecast figures move from Anaplan back into GP as unposted journal entry batches through export actions. The figures return unposted in an open fiscal period so a person reviews and posts them, which keeps the GP ledger authoritative.

How does the integration work when Dynamics GP is on-premises with no cloud API?

Microsoft Dynamics GP has no hosted endpoint, so the customer exposes their own server, usually the Service Based Architecture REST API or the SOAP Web Services through their firewall, or via a local agent inside the network. ml-connector authenticates with a Windows domain account over Kerberos or NTLM, since GP has no OAuth or API keys, and addresses the company by its SQL Server database name. It bridges that Windows login to the Anaplan token so the two systems can exchange data.

Does either system push data, or does ml-connector poll?

Neither system pushes events, so ml-connector polls both. GP has no webhooks, so it reads new and changed records incrementally on ModifiedDate where that field exists and by batch or status where it does not. Anaplan also has no webhooks and its bulk import and export tasks are asynchronous and lock the model, so the connector starts each task with a POST, polls the taskId until it reports complete, then runs the next one on a schedule tied to your close calendar.