Enterprise: ERP, CRM and SAP · Enterprise scenario · Proposed architecture

Intercompany orders and reconciliation across a holding (Intercompany Order Orchestration)

A customer order at Company A is fulfilled from Company B's warehouse: the contract, product codes and transfer price are checked, documents with mutual references are created in both companies, differences are resolved by the finance teams, and the result is shown on the holding dashboard.

Who it is for: Holdings with several legal entities and warehouses

Systems: Company A ERP environment, Company B ERP environment, Integration layer, Financial reconciliation and holding dashboard

Problem

Intercompany orders are opened by hand in two separate ERPs. A document is created in A but forgotten in B, or opened there with a different code. At month end, invoice, quantity and exchange rate differences are hunted down through email and spreadsheets.

How it works today

A sales rep at Company A calls Company B's warehouse, and the order is entered separately in B. Document numbers are not linked to each other. The intercompany invoice is created late, and reconciliation is done by hand between the finance teams at period close.

What this scenario changes

A customer order in A starts the process. A sourcing rule selects B, and the contract, code mapping and transfer price are checked in parallel. Linked documents are created separately in A and B, once each with an operation ID, and mutual references are stored. If a write fails on one side, only that side is recovered. Delivery, receipt, invoice and differences are tracked, and the result is shown on the holding dashboard.

The integration method is chosen based on the SAP version and the available interfaces.

Process stages

  1. Customer order and source: Determine the supply source for the order in A. Result: The order will be fulfilled from Company B's warehouse
  2. Intercompany checks: Check contract, product codes and transfer price at the same time. Result: Combined result of the three checks
  3. Transfer price: Check that the price complies with the intercompany rule. Result: Price within the rule or approved. Approval: A and B finance managers
  4. Linked document in A: Create the intercompany order in Company A exactly once. Result: Purchase Order in A
  5. Linked document in B: Create the counterpart document in B and store the references. Result: Sales Order in B, mutual IDs on both documents
  6. Delivery and receipt: Link B's shipment to A's receipt. Result: Delivery and Goods Receipt linked to each other
  7. Invoice and accounting: Prepare the intercompany invoice and accounting entries. Result: Invoice in B, accepted invoice and accounting entries in A
  8. Resolving differences: Check currency, quantity and amount differences. Result: No difference or an approved adjustment. Approval: A and B finance teams
  9. Holding dashboard: Show the reconciliation result at holding level. Result: Both companies' documents and difference status on one dashboard

Participants

The role of AI

When a difference appears, summarizes the causes (exchange rate date, period close, quantity) for the finance teams. It does not make adjustment or accounting decisions.

Rule-based automation

Contract, code mapping and transfer price are checked by rules. Writes in A and B are idempotent with separate operation IDs, and on a timeout the target ERP is searched first. Mutual identifiers are stored on both documents.

Human approval and exceptions

When the transfer price falls outside the rule, the A and B finance managers decide. The master data owner completes the code mapping. The finance teams resolve exchange rate and period differences. If the write on side B cannot be recovered, the integration operator and finance choose a cancellation or adjustment step together.

Frequently asked questions

Do you have a ready-made intercompany integration with SAP?

This page shows a proposed architecture and a synthetic demo. Each company's SAP version and processes may differ, and the integration method is chosen in the project based on the available interfaces.

If the document is not created in B, is the document in A deleted?

No. The document in A is kept and only side B is recovered. If recovery is not possible, the document in A is not deleted: it is moved to cancelled status with a reason. A single rollback across all systems is not promised.

Who resolves exchange rate and period differences?

A rule detects the difference, AI summarizes the cause, and the A and B finance teams approve the adjustment path. The adjustment is posted as a separate entry in the open period, and the existing document is not changed.

Adapt this solution to our company