Microsoft Dynamics GP and Basware integration

What moves between them

The main flow runs from Basware into Microsoft Dynamics GP. When an invoice is coded and approved, ml-connector reads it from accountingDocuments with its coding lines and creates a payables invoice in GP against the matching vendor, GL accounts, and cost objects. Vendor master data and GL accounts move the other direction, from GP into Basware, so the coding panel only offers accounts that exist in the ledger. After GP posts the payment, ml-connector sends a payment confirmation back to Basware so the document is marked paid. Cadence is event-driven where the Basware webhook fires, with scheduled polling of GP by modified date as the steady backstop.

How ml-connector handles it

ml-connector stores both credential sets encrypted and bridges the two auth models on every call: it requests a Basware OAuth2 bearer token and refreshes it when a call returns 401, while authenticating to GP with a Windows domain account over HTTP Negotiate or NTLM. Because GP is on-premises, the connector reaches it through the customer's exposed SBA endpoint or a local agent, and SBA write bodies are wrapped in the required Payload key. The Basware AccountingDocuments webhook is verified by recomputing the HMAC-SHA256 over the raw UTF-8 body and checking the timestamp before any GP write, since unicode in the payload will break a naive hash. Invoices land in GP as unposted Work transactions so they remain editable, and the connector polls GP vendors and transactions by modified date because GP emits no events. Basware silently drops an import that is identical to the prior version, so the connector changes a field when a record genuinely needs reprocessing, and it backs off on Basware 429 or 503 responses. Each record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized distributor with about 400 employees runs Microsoft Dynamics GP on its own servers for payables and the general ledger, and adopts Basware to digitize a paper-heavy invoice approval process across three branches. Before the integration, an AP clerk opened each approved invoice in Basware and typed the header, amount, vendor, and GL coding into GP by hand, and new suppliers had to be set up twice. With the two systems connected, every coded and approved Basware invoice posts into GP as an unposted voucher with its coding intact, vendors and accounts are created once in GP and imported into Basware, and once GP cuts the check the payment status flows back so nothing sits as open in Basware after it is paid.

What you can do

• •Create payables invoices in Microsoft Dynamics GP from coded and approved Basware accounting documents, with coding lines preserved.
• •Push GP vendors, GL accounts, and cost objects into Basware so invoice coding only references accounts that exist in the ledger.
• •Bridge Basware OAuth2 client credentials to GP Windows authentication and refresh the bearer token automatically.
• •Verify the Basware HMAC-SHA256 webhook over the raw UTF-8 body, then post invoices into GP as editable unposted transactions.
• •Send payment confirmations from GP back to Basware after posting, with retries and a full audit trail on every record.

Questions

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

The main flow is Basware into GP: coded and approved invoices become payables vouchers in GP. Vendors and GL accounts move from GP into Basware so coding stays valid, and payment confirmations flow from GP back into Basware once a check is posted. Basware never initiates payment, so the connector only confirms status, it does not push money.

How does the integration reconcile Basware OAuth2 with GP's Windows authentication?

Basware uses OAuth2 client credentials and returns a one-hour bearer token with no refresh token, while GP uses a Windows Active Directory account over Negotiate or NTLM. ml-connector stores both encrypted, requests a fresh Basware token at expiry, and presents the Windows credentials to GP on every call. Because GP is on-premises, it connects through the customer's exposed SBA endpoint or a local agent.

How are invoices kept from being duplicated or posted into a closed period?

Invoices are created in GP as unposted Work transactions, and supplying a duplicate document number raises a GP validation error rather than silently creating a duplicate. On the Basware side, an import identical to the prior version is silently skipped, so the connector only re-sends a record when a field actually changes. Postings target an open fiscal period, since GP rejects transactions dated into a closed period.