SAP S/4HANA and Procurify integration

What moves between them

The main flow runs from Procurify into SAP S/4HANA. Purchase orders and requisitions created in Procurify are read on a schedule and posted into SAP S/4HANA as purchase orders or purchase order line items, mapped to the correct GL accounts and cost centers. Vendor bills from Procurify flow into SAP as supplier invoices and GL account postings. Vendor master records are synced bidirectionally so both systems see the same supplier list, locations, and departments.

How ml-connector handles it

ml-connector stores both credential sets encrypted and manages the OAuth tokens independently on each side, since SAP uses Communication Arrangements while Procurify uses a standard client credentials flow. Since both systems poll only (neither supports webhooks), ml-connector polls Procurify at a cadence you define and writes to SAP S/4HANA's OData APIs. Procurify account codes and locations are mapped to SAP cost centers and GL accounts before posting, and the mapping is validated so every PO line references a valid GL account and cost center in SAP. Because GL Account and Cost Center APIs in SAP are read-only, ml-connector reads both on startup to build the validation table. SAP tokens require manual refresh handling, so ml-connector caches them and requests a new token before the 12-hour expiry. Procurify read-only endpoints like payments mean ml-connector never writes vendor payment data back into Procurify. Every record carries a full audit trail and can be replayed if a downstream SAP posting fails.

A real-world example

A mid-sized manufacturing company runs SAP S/4HANA for enterprise finance and procurement, and Procurify for decentralized purchase request management and vendor spend visibility. Before the integration, procurement managers submitted PO requests in Procurify, then the finance team manually entered approved orders into SAP S/4HANA, creating lag and duplicate data entry. Vendor master data was maintained in two places, leading to mismatched supplier lists at month-end close. With Procurify and SAP S/4HANA connected, each approved PO flows into SAP automatically, mapped to the correct cost centers for each department. Vendor records sync bidirectionally, so the procurement team always sees the authoritative supplier list, and the finance team starts close with PO and vendor data already in agreement.

What you can do

• •Sync purchase orders and requisitions from Procurify into SAP S/4HANA as purchase orders, mapped to the correct GL accounts and cost centers.
• •Post vendor bills and supplier invoice line items from Procurify into SAP, with full GL account allocation.
• •Keep vendor master records and locations aligned between Procurify and SAP S/4HANA so both systems see the same supplier list.
• •Validate all GL accounts and cost centers against SAP S/4HANA before writing, and maintain a lookup table refreshed on startup.
• •Poll Procurify on a custom schedule, handle OAuth token refresh for both systems independently, and track every record with a full audit trail.

Questions

Which direction does data move between SAP S/4HANA and Procurify?

The main flow is Procurify into SAP S/4HANA. Purchase orders, requisitions, and vendor bills move from Procurify into SAP, while vendor master records and location data are synced bidirectionally. Procurify payment endpoints are read-only, so ml-connector does not write payment data back into Procurify.

How does ml-connector handle the different OAuth flows on each side?

SAP S/4HANA uses OAuth 2.0 via Communication Arrangements with custom scopes, while Procurify uses standard client credentials flow with a 24-hour token lifetime. ml-connector manages both independently, caching SAP tokens and refreshing before the 12-hour expiry, and cycling Procurify tokens on the 24-hour boundary.

What happens if a PO references a cost center or GL account that does not exist in SAP S/4HANA?

ml-connector reads all GL accounts and cost centers from SAP on startup and validates every PO line before posting. If a Procurify account code or location does not map to a valid SAP cost center or GL account, the record is flagged in the audit trail and held in a queue for manual review, so bad data does not corrupt the general ledger.