Orders out on approval. Invoices back by reference.
This is the reference flow scoped with your SAP team — the transport channel changes per landscape, the shape of the loop does not.
Order approved in FilFlo
A quick-commerce or B2B purchase order is captured, cut at SKU level where needed, and approved — the commercial commitment is settled before SAP hears about it.
Material codes mapped per plant
FilFlo's per-site (per-CFA) item-code mapping carries the SAP material codes agreed during scoping, so each fulfilling plant receives its own codes — SAP master data stays the reference.
Sales order handed over the agreed channel
The order header and lines reach SAP through whichever surface the architecture supports: an API/OData call into S/4HANA, an IDoc through middleware such as SAP Integration Suite, or a secure scheduled file exchange. Never direct database access.
Rejections land in a designed error queue
The pattern requires an agreed error queue before automation switches on — SAP validation failures and blocks route back to FilFlo as actionable exceptions instead of disappearing into a log.
Billing document reference returns
Once SAP invoices the order, the billing document reference comes back to FilFlo through the same agreed channel — API, middleware, or scheduled file.
Invoice joins the order trail
The invoice reference is attached to the same order timeline as the PO, the approval, and the fulfillment events.
Downstream documents unlock
Invoice data read back from ERP powers downstream submissions — for example ASN filing to Zepto. This is the loop already running live against Dynamics 365.
This pattern is already live — against Dynamics 365.
The exact loop described on this page — approved orders pushed into ERP with per-site item codes, invoices read back into the order trail, ERP blocks surfaced as actionable exceptions — runs in production today against Microsoft Dynamics 365 Finance & Operations over its OData API, at an enterprise CPG deployment. An SAP engagement applies the same architecture through your SAP surfaces; the D365 page is the working proof of the design.
What crosses the wire — once scoped.
Created in SAP when the order is approved in FilFlo — header and line level. The exact object and surface (API/OData, IDoc via middleware, or file) is fixed during scoping.
SAP billing documents are read back through the agreed channel and attached to the FilFlo order trail, where they can feed downstream ASN submission.
FilFlo buyer entities are mapped to SAP customer / business partner records. SAP remains the master; FilFlo references, never rewrites.
Per-site (per-CFA) item-code mapping decides which SAP material codes each order carries. Ownership stays on the SAP side.
Orders are pushed against the correct SAP plant and storage location for the fulfilling site, as agreed in scoping.
What the pattern enforces — and what it expects.
SAP stays the financial and master-data authority
Accounting truth, customers, materials, plants and pricing live in SAP. FilFlo captures and resolves the commercial events that need to be clean before they reach ERP — it never writes around SAP controls.
Integration goes through your architecture
Every connection runs through a surface your SAP and basis teams approve: API/OData, IDocs via middleware such as SAP Integration Suite, or secure scheduled file exchange. No direct database access, ever.
Error queues designed before automation
Before any order flows automatically, scoping fixes where rejections land, who owns them, and how master-data conflicts get resolved — so exceptions have an owner from day one.
No packaged connector exists
This is an implementation pattern, not an off-the-shelf integration. Nothing is live against SAP today; every deployment is scoped against your landscape before a single order flows.
Modules and customizations vary
ECC and S/4HANA expose different surfaces, and module configuration and Z-customizations differ by company. Expect a scoping exercise with your SAP team, not a switch-on.
Master-data ownership must be settled first
Customers, materials, plants and pricing are referenced by FilFlo, not managed by it. Ownership rules and error queues must be designed before automation is turned on.
Frequently asked questions.
Does FilFlo have a native SAP connector?
No. SAP is an implementation pattern, not a packaged integration — no connector exists and nothing is live against SAP today. What FilFlo offers is a scoped integration through your own SAP architecture: API/OData into S/4HANA, IDocs through middleware such as SAP Integration Suite, or secure scheduled file exchange. The same order-out, invoice-back loop this pattern describes is running in production with Microsoft Dynamics 365 — that page documents the reference architecture.
Which SAP versions and modules does the pattern cover?
That is decided in scoping, not on this page. ECC and S/4HANA expose different integration surfaces, and module configuration and customizations vary by company — which is why every SAP engagement starts with your SAP or basis team agreeing the objects, the transport channel, master-data ownership and the error queue before any automation is switched on.
Does FilFlo replace SAP?
No. SAP remains the financial and master-data authority. FilFlo is the quick-commerce order-to-cash event layer around it — PO intake, SKU-level approvals, fulfillment, GST invoicing, GRNs and settlement-file credit notes — so the commercial events reaching SAP are already clean, approved and reconciliation-ready.
What has to be designed before automation switches on?
Two things above all: master-data ownership and error queues. Scoping fixes who owns customer, material and plant records, how FilFlo's mappings track them, where a rejected or blocked order lands, and who resolves it. Only once those answers exist does order flow move from supervised to automatic — the same discipline behind the live Dynamics 365 integration.
Scope the SAP pattern against a live reference.
Book a 30-minute demo: see the order-to-cash loop working end to end on the live Dynamics 365 integration, then walk through how the same architecture maps onto your SAP landscape — surfaces, master-data ownership and error queues included.