Sage 300 and Procurify integration

What moves between them

Purchase orders and order items flow from Procurify into Sage 300 as purchase orders and line items. Vendor records are synced in both directions so purchase orders land on vendors that exist in both systems. Payments are read from Procurify and recorded as AP adjustments or payment batches in Sage 300. All sync is pull-based, polling Procurify and Sage 300 on a schedule you control, typically daily or after approvals.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Procurify it refreshes the OAuth 2.0 bearer token when a request returns 401, and for Sage 300 it encodes the Basic Auth credentials with uppercase usernames as required by the API. Vendor names and account codes are mapped between the systems so purchase orders and payments reference vendors and GL accounts that exist in Sage 300. Because Sage 300 is self-hosted and exposes its own URL, ml-connector accepts the full HTTPS endpoint per customer. Because neither system supports webhooks, ml-connector polls both on a fixed schedule using date filters and pagination to fetch only new or changed records. Large volumes of calls (1500+) can trigger IIS timeouts unrelated to the API itself, so ml-connector batches requests to stay within safe thresholds. Every record carries a full audit trail so payment exceptions can be traced back to the Procurify source.

A real-world example

A mid-market manufacturing company runs Sage 300 on-premise for purchasing and accounting, and uses Procurify in the cloud for procurement and spend management across three locations. Before the integration, the procurement team approved purchase orders in Procurify and the AP team manually transcribed them into Sage 300 for receipt and matching. When payments were made in Procurify they were re-keyed into Sage 300 AP as well. With Sage 300 and Procurify connected, approved purchase orders flow into Sage 300 automatically, vendor names are kept in sync across both systems, and payments are recorded as AP adjustments without re-keying. The AP team now spends time on exceptions and three-way match rather than data entry.

What you can do

• •Move purchase orders and line items approved in Procurify into Sage 300 on a polling schedule you control.
• •Keep vendor records in sync between Procurify and Sage 300 so purchase orders and payments reference vendors that exist in both systems.
• •Record Procurify vendor payments as AP adjustments or payment batches in Sage 300 with full account mapping.
• •Authenticate Procurify via OAuth 2.0 and Sage 300 via HTTP Basic Auth with uppercase credential handling, and refresh tokens when they expire.
• •Poll both systems on your schedule with date filters and pagination, tracking every record in a full audit trail.

Questions

Which direction does data move between Sage 300 and Procurify?

Purchase orders, order items, and payments move from Procurify into Sage 300. Vendor master data is synced in both directions so purchase orders and payments reference vendors that exist in both systems. Sage 300 is the source of truth for accounting; Procurify is the source of truth for procurement approvals.

Does Sage 300's self-hosted setup require special configuration?

Yes. Sage 300 is an on-premise system, so your IIS server must be exposed over HTTPS and accessible from the internet. A dedicated API user account must be created in Administrative Services with Web API security group permissions. The username and password must be uppercase and are sent with every request in the Authorization header.

How does ml-connector handle Procurify's OAuth 2.0 requirement?

ml-connector stores the OAuth client credentials encrypted, obtains a bearer token on your schedule, and refreshes it when a request returns 401. Each sync cycle uses the valid token to poll purchase orders, payments, and vendor records. Procurify tokens expire after 24 hours, so ml-connector requests a fresh token at the start of each polling cycle.