SAP ECC and Procore integration

What moves between them

The primary flow is SAP ECC to Procore. Vendor master data (LFA1 table) syncs into Procore Vendors on a weekly or monthly schedule. Purchase order headers and line items (EKKO and EKPO) sync into Procore Purchase Order Contracts and line-level Requisitions mapped to cost codes. GL cost allocations (BSEG table, filtered by cost center) sync as Direct Costs posted against the mapped Procore project and cost code. No data flows back from Procore to SAP ECC; Procore is read and write, SAP ECC is read-only.

How ml-connector handles it

ml-connector runs an on-premises polling agent that establishes RFC connections to SAP ECC using the customer's Basic Auth credentials and pulls vendor, PO, and GL data via RFC_READ_TABLE or RFC_GET_TABLE on a scheduled cadence tied to the accounting period or project billing cycle. SAP ECC RFC calls have a typical safe throughput of 10-50 concurrent calls before raising SYSTEM_FAILURE exceptions, so ml-connector batches reads in chunks and retries with exponential backoff. Vendor records are mapped to Procore Vendor entities, PO lines to Purchase Order Contracts, and GL cost center allocations to Direct Costs using cost code mapping tables stored in the integration configuration. Because SAP ECC's BAPI_ACC_DOCUMENT_POST has no built-in idempotency mechanism, ml-connector uses the REF_DOC_NO field to detect duplicate GL postings on retry and prevent double-entry. On the Procore side, ml-connector authenticates via OAuth 2.0 client credentials, refreshes the bearer token every 4800 seconds to avoid expiry mid-sync, and batches upserts to stay well below Procore's standard rate limits. Every vendor, PO, and cost line carries an external ID so re-runs are idempotent. Failed records are logged with full diagnostic context and can be manually replayed after the root cause is fixed.

A real-world example

A mid-sized commercial construction firm runs SAP ECC at headquarters for accounting and procurement, and deploys Procore to 150+ active job sites for field cost tracking and contract management. Before integration, each project manager had to download a PO export from SAP every week, open it in Excel, map line items to Procore cost codes by hand, and upload rows into each project. GL month-end reconciliation between Procore project costs and SAP labor accounts took 10 days of chasing line-by-line variances. With SAP ECC and Procore connected, weekly PO syncs automatically populate Procore with current commitments, labor cost distributions from SAP GL flow into Procore as direct costs mapped to project cost codes, and project managers see live GL alignment with no manual mapping. Month-end close is compressed from 10 days to 2.

What you can do

• •Sync vendor master data from SAP ECC to Procore on a weekly or monthly schedule, keeping vendor names, tax IDs, and payment terms current across both systems.
• •Move purchase order headers and line items from SAP ECC into Procore as purchase order contracts and requisitions, mapped to project cost codes.
• •Post SAP ECC general ledger cost allocations into Procore as direct costs, grouped by cost center and cost code so project managers see labor and overhead spending in real time.
• •Authenticate against SAP ECC's on-premises RFC/BAPI endpoints via Basic Auth and an on-site polling agent, and Procore via OAuth 2.0 client credentials from a Developer Managed Service Account.
• •Handle RFC connection pooling, batching, and retries with exponential backoff; use cost center mapping tables to allocate GL lines correctly; and track external IDs to prevent duplicate PO and cost entries across syncs.

Questions

Why is an on-site agent required to connect to SAP ECC?

SAP ECC is on-premises and exposes data through RFC/BAPI, which cannot be called from the cloud. ml-connector deploys an agent on the customer's network that runs the SAP .NET Connector or Java Connector, establishes RFC sessions to SAP ECC using the customer's Basic Auth credentials, and polls data on a schedule. The agent runs within the customer's firewall and sends the retrieved data to ml-connector's cloud endpoint.

How are GL postings handled if SAP ECC BAPI has no idempotency key?

ml-connector uses SAP ECC's REF_DOC_NO field to detect duplicate GL postings on retry. Each sync run assigns a unique reference number to every GL line being posted; if a write fails and is retried, the duplicate check catches the REF_DOC_NO and skips re-posting. This prevents double-entry in the ledger even if the network fails mid-sync.

What happens if a vendor or PO sync fails partway through?

ml-connector logs each record with its external ID and sync state. If a batch fails, the agent pauses, logs diagnostic context to the audit trail, and waits for the next scheduled window. On the retry, ml-connector compares external IDs and skips records already in Procore, so re-running a failed sync is idempotent and does not create duplicates.