How does ml-connector connect to SAP ECC if it is on-premises and Procurify is cloud?

The SAP on-premises agent (SAP .NET Connector or Java Connector) runs on the customer network and accepts incoming RFC calls from ml-connector. ml-connector connects to the agent using the agent's configured RFC destination, passes HTTP Basic Auth credentials, and issues BAPI and RFC_READ_TABLE calls through the agent. OData calls use HTTP Basic Auth against SAP Gateway at the customer's SAP ECC instance URL. The agent and OData services are both on the customer network, so the cloud integration works through these on-premises endpoints without requiring a dedicated tunnel.

What happens if a purchase order is rejected in SAP ECC after ml-connector sends it?

ml-connector detects the rejection through the return code from BAPI_PO_CREATE1 or BAPI_PO_CHANGE (errors such as 'GL account does not exist' or 'cost center invalid'). It logs the failure with the full BAPI error message, records the rejection in the audit trail, and stops processing that order until the GL code or cost center is corrected in Procurify or SAP ECC. The operator reviews the audit log, fixes the configuration (for example, mapping Procurify's IT department to the correct SAP cost center), and retriggers the sync.

Can ml-connector post vendor bills back to Procurify after they are received in SAP ECC?

No. Procurify bills are read-only via the API, and the bills endpoint does not accept writes. The flow is one-way: bills flow from Procurify into SAP ECC via BAPI_ACC_DOCUMENT_POST. If a bill is created or modified in SAP ECC outside of Procurify, those changes remain in SAP ECC; Procurify retains the source record of the bill.

SAP ECCProcurify

SAP ECC and Procurify integration

SAP ECC drives procurement and finance at the ERP layer. Procurify handles the procurement workflow in the cloud, from requisition through payment. Connecting them keeps purchase orders, vendor master data, and payables synchronized without manual re-entry. When a requisition is approved in Procurify, the order flows into SAP ECC's PO system automatically. When a vendor bill arrives, it posts into SAP ECC's general ledger with full audit and the correct GL coding. The connection eliminates duplicate data entry and keeps both systems a single source of truth.

How SAP ECC works

SAP ECC exposes purchase orders, vendors, bills, GL accounts, and cost centers through RFC/BAPI function modules and OData v2 REST services, each secured by HTTP Basic Auth. The on-premises deployment requires an SAP NCo or JCo agent running on the customer network; RFC calls cannot originate directly from the cloud. Key functions include BAPI_PO_CREATE1 and BAPI_PO_CHANGE for purchase orders, BAPI_VENDOR_GETLIST and BAPI_VENDOR_CHANGE for vendor master, BAPI_ACC_DOCUMENT_POST for general ledger postings, and RFC_READ_TABLE for raw table queries. OData services must be manually activated by the SAP Basis team via TCODE SICF. There is no native webhook system; integration requires polling on a schedule or on-demand via the on-premises agent, or receiving outbound IDoc XML push where the customer configures WE21/WE20 ports.

How Procurify works

Procurify exposes purchase requisitions, purchase orders, order items, bills, vendors, and payment methods through a cloud REST API. All endpoints require OAuth 2.0 client credentials (client_id and client_secret) and return JSON. The API supports time-based polling with date-range filters such as last_modified and po_created_date on v3 endpoints. There are no webhooks, event subscriptions, or push notifications. Key resources include vendors, purchase-orders, requisitions, bills, and payments. The API is marked evolving and subject to change. Purchase orders are generated from approved requisitions and order items in the workflow; order items and payments are read-only via the API. Access requires prior contact with the Procurify representative, and excessive concurrent requests may trigger access suspension.

What moves between them

The main flow is Procurify into SAP ECC. ml-connector polls Procurify for new and modified purchase requisitions and orders on a schedule, reads approved orders, vendor payment methods, and bills, then writes approved orders into SAP ECC as purchase orders (BAPI_PO_CREATE1) and updates existing orders (BAPI_PO_CHANGE). Vendor records sync bidirectionally: Procurify vendors are upserted into SAP ECC's vendor master (BAPI_VENDOR_CHANGE), and new SAP ECC vendors are optionally added to Procurify. Received bills are posted into SAP ECC's general ledger (BAPI_ACC_DOCUMENT_POST) with GL codes, cost centers, and the vendor line item allocation. SAP ECC purchase orders and vendor master are the authoritative source for GL coding; Procurify is authoritative for workflow state and payment terms.

How ml-connector handles it

ml-connector establishes the RFC connection through the customer's on-premises SAP NCo or JCo agent, passing HTTP Basic Auth credentials to SAP Gateway for OData fallback endpoints. On the Procurify side it obtains an OAuth 2.0 bearer token from the token endpoint and refreshes it on each 24-hour expiry or 401 response. When polling Procurify, it filters by date-modified timestamps to avoid full-table scans and caches last-sync positions. On each poll cycle, requisitions marked approved in Procurify are mapped to SAP ECC GL codes and cost centers (based on Procurify department / account-code fields), then pushed into SAP ECC with BAPI_PO_CREATE1. Updates to existing orders call BAPI_PO_CHANGE with the same GL mapping. Bill postings call BAPI_ACC_DOCUMENT_POST with explicit BAPI_TRANSACTION_COMMIT to lock the document in SAP ECC. For retry deduplication, ml-connector uses SAP ECC's REF_DOC_NO field to detect duplicate bill posts by Procurify bill ID; a repeat POST returns 204 No Content instead of inserting a second copy. The on-premises agent enforces SAP RFC throughput limits (typical 10-50 concurrent calls); ml-connector batches polls and queues BAPI calls to stay within the safe window and backs off on SYSTEM_FAILURE exceptions. All records carry a full audit trail (timestamp, Procurify bill ID, SAP document number, GL code used, cost center allocated) and can be replayed if a downstream BAPI call fails.

A real-world example

A mid-market manufacturing company runs SAP ECC on-premises for procurement and finance, and deployed Procurify to bring visibility to purchase requisitions and vendor spend across three plants. Before integration, procurement staff approved orders in Procurify but then manually entered them into SAP ECC, and accounts payable reconciled Procurify bills against SAP ECC PO lines by hand each week. With SAP ECC and Procurify connected, approved purchase requisitions flow automatically into SAP ECC as purchase orders with the correct GL codes for each plant, vendors are kept in sync so new Procurify vendors show up in SAP ECC within minutes, and when a bill is received, it posts directly into SAP ECC's accounts payable and general ledger sub-ledger without re-keying. The two systems stay aligned, month-end accruals are pre-populated and verified, and the manual PO and bill entry work is eliminated.

What you can do

Sync approved purchase requisitions and orders from Procurify into SAP ECC purchase order tables via BAPI_PO_CREATE1 and BAPI_PO_CHANGE, with GL codes and cost centers mapped from Procurify departments.
Keep vendor master records synchronized between Procurify and SAP ECC using BAPI_VENDOR_CHANGE, so new vendors in Procurify are added to SAP ECC automatically.
Post vendor bills received in Procurify into SAP ECC's general ledger with BAPI_ACC_DOCUMENT_POST, allocated to the matching GL account and cost center, with duplicate-detection using SAP ECC REF_DOC_NO.
Manage the SAP on-premises agent connection and HTTP Basic Auth for OData services, and handle OAuth 2.0 token refresh and 401 retries on the Procurify side.
Poll Procurify on a schedule with date-filtered queries, batch BAPI calls within RFC throughput limits, detect and replay failed postings, and maintain a complete audit trail of every synced order and bill.

Questions

How does ml-connector connect to SAP ECC if it is on-premises and Procurify is cloud?: The SAP on-premises agent (SAP .NET Connector or Java Connector) runs on the customer network and accepts incoming RFC calls from ml-connector. ml-connector connects to the agent using the agent's configured RFC destination, passes HTTP Basic Auth credentials, and issues BAPI and RFC_READ_TABLE calls through the agent. OData calls use HTTP Basic Auth against SAP Gateway at the customer's SAP ECC instance URL. The agent and OData services are both on the customer network, so the cloud integration works through these on-premises endpoints without requiring a dedicated tunnel.
What happens if a purchase order is rejected in SAP ECC after ml-connector sends it?: ml-connector detects the rejection through the return code from BAPI_PO_CREATE1 or BAPI_PO_CHANGE (errors such as 'GL account does not exist' or 'cost center invalid'). It logs the failure with the full BAPI error message, records the rejection in the audit trail, and stops processing that order until the GL code or cost center is corrected in Procurify or SAP ECC. The operator reviews the audit log, fixes the configuration (for example, mapping Procurify's IT department to the correct SAP cost center), and retriggers the sync.
Can ml-connector post vendor bills back to Procurify after they are received in SAP ECC?: No. Procurify bills are read-only via the API, and the bills endpoint does not accept writes. The flow is one-way: bills flow from Procurify into SAP ECC via BAPI_ACC_DOCUMENT_POST. If a bill is created or modified in SAP ECC outside of Procurify, those changes remain in SAP ECC; Procurify retains the source record of the bill.

Connect SAP ECC and Procurify

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started