Acumatica and Ramp integration

What moves between them

Two flows run in opposite directions. Reference data moves from Acumatica into Ramp: vendors, GL accounts, and dimensions such as subaccounts, branches, and departments are pushed into Ramp's GL accounts and field options so card and bill spend can be coded against the real chart of accounts. Spend moves from Ramp into Acumatica: coded and approved Ramp card transactions and bills become Acumatica AP bills and GL journal transactions, posted against the matching vendor and account, and only when Ramp marks them ready to sync. Acumatica stays the system of record for the ledger, so ml-connector writes financial documents only into Acumatica and never alters posted Acumatica entries from Ramp.

How ml-connector handles it

ml-connector stores both credential sets encrypted and pins the Acumatica endpoint version per customer, since the version in the URL must match the ERP release exactly or every call returns 404, and it wraps all Acumatica field values in the required value objects. On the Ramp side it exchanges client credentials for a ten-day access token over HTTP Basic auth and refreshes daily rather than waiting for a 401. Because Acumatica cloud push is not guaranteed, the connector polls vendors, accounts, and bills on LastModifiedDateTime with $top and $skip paging and a stored high-water mark, while consuming Ramp bills.synced, bills.paid, and transactions.synced webhooks, verifying the HMAC-SHA256 signature and re-fetching each object since Ramp webhooks are non-authoritative. Vendors and GL accounts are mapped first so each Ramp transaction posts to an existing Acumatica vendor and account, and Ramp dimensions align with Acumatica subaccounts and branches. Every Ramp write carries an Idempotency-Key and every Acumatica post is deduped by vendor reference, so a retried delivery never books an AP bill twice; Ramp returns HTTP 429 above 100 requests per minute and Acumatica returns 429 under its license-tier limit, so ml-connector backs off and retries with a full audit trail on every record.

A real-world example

A mid-sized professional services firm with about 200 staff runs Acumatica for its general ledger and accounts payable, and issues Ramp corporate cards across its consulting and operations teams. Before the integration, the accounting team exported Ramp transactions to a spreadsheet each week and keyed them into Acumatica as AP bills and journal entries, matching each charge to a vendor and GL account by hand, which left card spend uncoded until well into month-end close. With Acumatica and Ramp connected, the chart of accounts, vendors, and departments publish into Ramp so cardholders see valid coding options at the point of spend, and every approved transaction posts back into Acumatica against the right account. Spend is coded as it happens and the manual weekly import is gone.

What you can do

• •Publish Acumatica vendors, GL accounts, and dimensions into Ramp as coding options for card and bill spend.
• •Post coded Ramp card transactions into Acumatica as AP bills or GL journal entries against the matching vendor and account.
• •Bring approved Ramp bills into Acumatica as AP bills, mapped to the right vendor, account, and dimensions.
• •Bridge Acumatica OAuth and version-locked endpoints with Ramp OAuth 2.0 client-credentials tokens.
• •Verify Ramp HMAC-SHA256 webhooks and poll Acumatica on LastModifiedDateTime, with idempotent retries and a full audit trail.

Questions

Which direction does data move between Acumatica and Ramp?

Both directions, by record type. Vendors, GL accounts, and dimensions move from Acumatica into Ramp as coding options, while coded card transactions and approved bills move from Ramp into Acumatica as AP bills and journal entries. Acumatica stays the system of record for the ledger, so ml-connector writes accounting documents only into Acumatica and does not change posted entries from Ramp.

How does the integration handle Acumatica's version-locked endpoints and Ramp's token model?

ml-connector pins the Acumatica endpoint version per customer because a mismatched version in the URL returns 404, and it wraps every Acumatica field value in the required value object. For Ramp it exchanges client credentials for an access token over HTTP Basic auth, and because that token lasts ten days it refreshes daily rather than waiting for an expiry error.

Does the integration use webhooks or polling, and how does it avoid duplicate AP bills?

It uses both, matched to each system. ml-connector consumes Ramp bills and transaction webhooks, verifying the HMAC-SHA256 signature and re-fetching each object since Ramp webhooks are non-authoritative, and it polls Acumatica on LastModifiedDateTime because Acumatica cloud push is not guaranteed. Each Ramp write carries an Idempotency-Key and each Acumatica post is deduped by vendor reference, so a retried delivery never books the same AP bill twice.