Acumatica and Procurify integration

What moves between them

The main flow runs from Procurify into Acumatica. As purchase orders and AP bills are approved in Procurify, ml-connector reads them and posts them into Acumatica as PurchaseOrder and Bill records, each linked to the matching Acumatica vendor and GL account. Reference data moves the other direction: Acumatica vendors and chart-of-account changes flow back into Procurify so every requisition is coded to a vendor and account code that exists in the ledger. Purchase order and payment status can be read from Acumatica and reflected against the originating Procurify orders so requesters see fulfillment. Cadence is scheduled polling on both sides, since Procurify has no webhooks and Acumatica push is optional.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Procurify side it fetches a client-credentials token, caches it for its 24-hour life, and sends it with the required X-Procurify-Client api header on every call. On the Acumatica side it accepts the full tenant URL and the exact endpoint version per customer, since the path is version-locked and a mismatch returns 404, and it wraps every field value in the value-object shape Acumatica requires. Because neither side guarantees a push, it polls Procurify by date-range filter and walks page-number pages, and polls Acumatica on the LastModifiedDateTime high-water mark with top and skip offset paging. Vendors and account codes are mapped first, so every Procurify bill lands on a valid Acumatica vendor and GL account. Acumatica has no idempotency-key header, so before creating a Bill ml-connector checks for an existing record by the vendor reference and uses PUT upsert, which guards against duplicates when a poll overlaps. Acumatica rate limits return HTTP 429 and Procurify can suspend access on excessive requests, so calls back off and retry, and every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-sized engineering firm with roughly 300 staff across three offices runs Acumatica for finance and accounts payable and rolled out Procurify so department managers could raise purchase requests and approvals on their own. Before the integration, the AP team re-keyed every approved purchase order and supplier bill from Procurify into Acumatica by hand, and requisitions frequently picked vendors or account codes that did not match the ledger, which meant bills bounced back for correction. With Acumatica and Procurify connected, approved purchase orders and bills post into Acumatica automatically against the right vendor and GL account, and the vendor and chart-of-account list in Procurify stays in step with finance. The re-keying queue disappears and miscoded requests stop reaching AP.

What you can do

• •Post approved Procurify purchase orders and AP bills into Acumatica as PurchaseOrder and Bill records against the matching vendor and account.
• •Sync Acumatica vendors and GL account codes back into Procurify so every requisition is coded to a valid ledger entry.
• •Reflect Acumatica purchase order and payment status against the originating Procurify orders so requesters see fulfillment.
• •Authenticate Procurify with its client-credentials token and Acumatica with its tenant-specific OAuth flow and version-locked endpoint.
• •Poll both systems on your schedule with backoff, idempotent upserts, retries, and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Procurify?

The main flow is Procurify into Acumatica. Approved purchase orders and AP bills move from Procurify into Acumatica as PurchaseOrder and Bill records, while vendors and GL account codes flow from Acumatica back into Procurify as reference data. Purchase order and payment status can also be read from Acumatica and shown against the originating Procurify orders.

Does the integration rely on webhooks?

No. Procurify does not support webhooks at all, and Acumatica's Push Notifications feature is optional and unsigned, so ml-connector treats both sides as pull. It polls Procurify with date-range filters and page-number paging, and polls Acumatica on the LastModifiedDateTime high-water mark with offset paging, on the schedule you set.

How are duplicate bills avoided when Acumatica has no idempotency key?

Acumatica provides no idempotency-key header, so ml-connector checks for an existing record by the vendor reference before creating a Bill and uses PUT upsert semantics, which update the record if it already exists. Combined with a stored high-water mark on each poll, this prevents the same Procurify bill from posting twice when sync windows overlap.