Microsoft Dynamics GP and Ramp integration

What moves between them

The main flow moves vendors and purchase orders from Dynamics GP into Ramp on a scheduled polling interval set by the customer. New and updated vendors in Dynamics GP appear in Ramp's vendor list so purchasing teams see the current vendor master. Purchase orders in Dynamics GP sync into Ramp as read-only records for visibility. Bills created or updated in Ramp flow back into Dynamics GP's payables module and are coded to the same GL accounts and cost centers that exist in Dynamics GP. Paid bills in Ramp trigger journal entries in Dynamics GP's general ledger. The integration operates at a cadence tied to the customer's purchasing and billing cycle, typically daily or weekly.

How ml-connector handles it

ml-connector stores both Dynamics GP Windows domain credentials and Ramp OAuth 2.0 client credentials encrypted. On the Dynamics GP side, it opens a Windows auth session using the customer-provided domain account and polls the SBA REST endpoint (or SOAP Web Services for older installations) at the customer's specified server and port, filtering for vendors and purchase orders modified since the last sync. It wraps any POST or PATCH payloads in the required Payload key and respects the constraint that write operations only succeed on unposted transactions. On the Ramp side, it refreshes the OAuth 2.0 access token every 9 days (before expiry) and presents it on each request. Vendors from Dynamics GP are matched to Ramp's vendor master by name and ID; GL accounts on bills are validated against Dynamics GP's chart of accounts before posting. When Ramp webhooks are enabled, bills marked paid trigger Ramp to push an event to ml-connector, which reads the bill and posts it back into Dynamics GP as a journal entry in the corresponding payables period. Every record carries a timestamp and sync status; failed records are retried with exponential backoff and logged for manual review.

A real-world example

A mid-sized manufacturing distributor runs Dynamics GP on-premises for its core financials and purchasing. The company uses Ramp's corporate cards and bill pay for operational expenses and vendor invoices. Before the integration, the accounts payable team received purchase orders from the Dynamics GP purchasing team and manually keyed them into Ramp to track which bills came from which purchase orders. When bills were paid through Ramp, the team exported the details and re-entered them into Dynamics GP's payables module so the GL balances matched. Month-end close involved a manual reconciliation between the Ramp bill register and the Dynamics GP payables aging report. With Dynamics GP and Ramp connected, purchase orders flow automatically into Ramp without re-keying, vendors stay synchronized with the master list in Dynamics GP, and paid bills post into the GL automatically with the correct account coding. The AP team now confirms the bills are correct in Ramp and they post into Dynamics GP with no additional data entry.

What you can do

• •Sync vendors from Dynamics GP into Ramp's vendor list on a scheduled polling interval.
• •Sync purchase orders from Dynamics GP into Ramp as read-only records for visibility and matching.
• •Post paid bills from Ramp back into Dynamics GP's payables module and GL with correct account coding.
• •Authenticate Dynamics GP with Windows domain credentials and Ramp with OAuth 2.0, managing credential expiry and refresh.
• •Validate GL accounts on all transactions against Dynamics GP's chart of accounts to prevent posting to invalid accounts.

Questions

How does ml-connector handle Dynamics GP's Windows domain authentication when it runs in a cloud environment?

ml-connector stores the Windows domain account credentials encrypted and opens a Windows auth session (Kerberos or NTLM) when it needs to poll Dynamics GP. The customer exposes their Dynamics GP server (SBA or SOAP endpoint) through their firewall with a valid SSL certificate or through a local forwarding agent, so ml-connector can reach it securely from the cloud. The domain account is created by the customer's Active Directory team and granted the necessary Dynamics GP user role.

Why does ml-connector poll Dynamics GP instead of using webhooks?

Dynamics GP does not support webhooks or push notifications. ml-connector polls the SBA REST endpoint (or SOAP Web Services) at intervals you define, using ModifiedDate filters to fetch only records changed since the last sync. This approach avoids re-keying manual purchases and keeps the two systems aligned on your schedule.

What happens if a bill in Ramp is coded to a GL account that does not exist in Dynamics GP?

ml-connector validates every GL account on a bill against Dynamics GP's chart of accounts before posting. If an account does not exist, the sync fails and the record is logged for manual review so the Ramp account can be corrected or the account can be created in Dynamics GP. This prevents the general ledger from becoming unbalanced.