Microsoft Dynamics GP and BILL integration

What moves between them

The main flow runs from Microsoft Dynamics GP into BILL. ml-connector reads vendors and approved payables invoices from GP and creates or updates them as vendors and bills in BILL, mapping GP vendor IDs to BILL vendors and GP GL accounts to BILL chart-of-accounts entries. Payment results flow the other direction: as BILL processes a payment, ml-connector records that payment against the matching payables document in GP so the ledger reflects what was paid. Vendor master changes are kept aligned in both directions, and purchase orders stay in GP because BILL has no PO object.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Microsoft Dynamics GP it accepts the customer SBA base URL, tenant, company database name, and Windows domain account, and authenticates each request with Windows Negotiate or NTLM against the exposed endpoint. For BILL it posts the developer key and org credentials to the login endpoint, caches the returned sessionId, and re-logins and retries automatically when a call returns an auth error, since BILL signals an expired session as a 401 rather than a clear code. Because GP has no webhooks, GP is read by polling list endpoints filtered on ModifiedDate on the schedule you set, while BILL payment and bill events can arrive by signed webhook to drive write-back faster. Vendor IDs and GL accounts are mapped first so every bill and payment lands on records that already exist on both sides. BILL allows only three concurrent calls per org, so requests are queued and throttled, and rate-limit responses are backed off and retried. Posted GP transactions are read-only, so payment write-back targets the correct payables document and applies the payment rather than editing a closed record. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized building products distributor with around 150 employees runs Microsoft Dynamics GP on its own server for financials and purchasing, and adopts BILL so its AP team can approve and pay vendors from the cloud instead of cutting checks by hand. Before the integration, a clerk re-typed each approved GP invoice into BILL and then re-entered the payment confirmation back into GP, which was slow and produced mismatched vendor records and a payables ledger that drifted from what BILL actually paid. With Microsoft Dynamics GP and BILL connected, approved payables flow into BILL as bills automatically and the payment status posts back into the GP ledger, so the two systems stay reconciled and the duplicate data entry is gone.

What you can do

• •Create and update BILL vendors and bills from approved Microsoft Dynamics GP vendors and payables invoices.
• •Post BILL payment results back into the GP payables ledger so the ledger reflects what was paid.
• •Map GP vendor IDs and GL accounts to the matching BILL vendor and chart-of-accounts records.
• •Bridge GP Windows authentication on a customer-exposed endpoint to the BILL session-token API, refreshing the session on expiry.
• •Poll GP on the schedule you set, queue within the BILL three-call concurrency limit, and keep a full audit trail with replay on every record.

Questions

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

The main flow is GP into BILL: vendors and approved payables invoices move from Microsoft Dynamics GP into BILL as vendors and bills. Payment status moves the other way, from BILL back into the GP payables ledger, and vendor records are kept aligned in both directions. Purchase orders stay in GP because BILL has no purchase order object.

How does the integration handle GP Windows authentication and the BILL session token?

Microsoft Dynamics GP uses a Windows Active Directory account on a customer-exposed SBA or SOAP endpoint, while BILL uses a session token obtained from a developer-key login. ml-connector stores both sets of credentials encrypted, presents Windows auth to GP, and caches the BILL sessionId. Because BILL sessions expire after 35 minutes of inactivity and report expiry as a 401, ml-connector re-logins and retries automatically.

Does GP push changes to BILL, or are they polled?

GP is polled, because Dynamics GP has no webhook or event mechanism. ml-connector reads GP list endpoints filtered on ModifiedDate on the schedule you set to detect new and changed vendors and payables. BILL can push HMAC-SHA256 signed webhooks for bill and payment events, so write-back into GP can be triggered as those events arrive rather than waiting for the next poll.