Microsoft Dynamics GP and AvidXchange integration

What moves between them

Vendors and GL accounts move from Microsoft Dynamics GP into AvidXchange so invoices can be coded and routed correctly, since a vendor must exist in AvidXchange before a payment can be made. Posted payables invoices are submitted from GP as AvidXchange invoices, with line items mapped to GL codes and the invoice image attached. After AvidPay executes a payment, the settled record with check number, ACH trace, or virtual card detail is pulled back from AvidXchange and recorded against the matching GP vendor and AP account. Vendor and GL sync runs on a recurring cadence, payment read-back is polled every 15 to 30 minutes, and invoice status is checked after each batch.

How ml-connector handles it

ml-connector stores both credential sets encrypted, presents the Windows domain account on every Dynamics GP request over Negotiate or NTLM, and sends the AvidXchange Company and User tokens as headers on every call. Because GP is on-premises, the customer must reach it through a firewall opening with a valid certificate or through a local agent on their network, and ml-connector accepts the full SBA base URL plus the SQL database name as the company. Neither system offers webhooks, so it polls GP for changed vendors and invoices by ModifiedDate and polls AvidXchange for payment and invoice status on a schedule rather than waiting for a push. Vendors and GL accounts are mapped and synced first so every submitted invoice line references a vendor and GL code that already exists in AvidXchange. GP only allows writes against unposted work transactions and rejects activity in a closed fiscal period, so it is treated mostly as a read source for invoices, while AvidXchange batch IDs are tracked and GP is checked by document number before posting to avoid duplicates. GP has no published rate limit but its throughput is bound by the customer's SQL Server, so ml-connector caps concurrency and spaces out writes, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized construction firm with about two hundred staff runs Microsoft Dynamics GP on its own server for the general ledger and accounts payable, and uses AvidXchange to scan, code, approve, and pay subcontractor and supplier invoices. Before the integration, AP clerks exported vendor lists and approved bills from GP and rekeyed them into AvidXchange, then manually entered each completed check and ACH payment back into the ledger, which slowed the month-end close and left vendor records out of step between the two systems. With Microsoft Dynamics GP and AvidXchange connected, vendors and GL codes stay aligned, payables invoices flow into AvidXchange for payment, and settled payment detail posts back into GP automatically. The accounting team starts the close with AP already reconciled and the manual re-entry removed.

What you can do

• •Sync Microsoft Dynamics GP vendors and GL accounts into AvidXchange so invoices can be coded and paid against valid records.
• •Submit posted Dynamics GP payables invoices into AvidXchange as invoices, with line-level GL coding and the invoice image attached.
• •Pull settled check, ACH, and virtual card payment detail from AvidXchange and record it against the matching GP vendor and AP account.
• •Bridge GP Windows authentication, reached over a firewall opening or local agent, to the AvidXchange Company and User token headers.
• •Poll both systems on a schedule with batch-ID tracking, retries, and a full audit trail on every record.

Questions

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

Vendors, GL accounts, and posted payables invoices move from Dynamics GP into AvidXchange so invoices can be coded and paid. After payment is executed, the settled payment detail is pulled back from AvidXchange and recorded in GP. Vendors must exist in AvidXchange before invoices can be paid, so vendor sync runs first.

Dynamics GP is on-premises with no webhooks. How does ml-connector reach it and stay current?

GP has no cloud endpoint, so the customer exposes its SBA REST or SOAP service through a firewall opening with a valid certificate, or runs a local agent on their network that ml-connector calls. Neither GP nor AvidXchange supports webhooks, so ml-connector polls on a schedule: it reads changed GP vendors and invoices by ModifiedDate and checks AvidXchange payment and invoice status every 15 to 30 minutes. Polling concurrency is capped because GP throughput depends on the customer's SQL Server.

How does the integration handle the two different authentication models?

Dynamics GP uses Windows authentication tied to Active Directory, with a dedicated domain account presented over Negotiate or NTLM, while AvidXchange uses proprietary Company and User tokens passed as headers. ml-connector stores both credential sets encrypted, presents the Windows account on every GP request, and attaches the AvidXchange tokens on every call. The GP company in each request is the SQL Server database name rather than the display name.