ANONYMIZED CASE · CPG
CAPEX/OPEX budget governed over the graph, integrated to the ERP without extending the core
A regional food & beverage company implemented over EAFlow —as a new implementation, not as a migration from a previous tool— a governed Budget Approval Workflow for Finance Shared Services: form by type (CAPEX/OPEX) with master data from the graph, multi-level approver chain by cost center, observations and rework, and service integration to the financial ERP —each request as a traceable case file.
The validation showed that the solution works over the client's operation and the value it delivers: the budget is governed over the graph and reaches the ERP by service without extending the core, with the approval chain and the audit trail as a by-product of the flow.
The challenge
In a regional food & beverage company that manages its CAPEX/OPEX budget over email and spreadsheets, the pattern repeats: the process works, but it leaves no trail.
- The approval process lives in email and spreadsheets. The approval model, master data and forms are not in any governed system; every budget extension is a chain of messages with no state.
- Master data lives in parallel spreadsheets. Cost centers, accounts, categories, asset class and the approver chain are not connected to the rest of the operational model.
- The ERP load is manual. Once approved, the request is re-keyed into the financial ERP, with error risk and no trail tying the approval to the record.
- Failed loads are redone by hand. When an approved request does not reach the ERP, someone reprocesses it case by case, with no error classification and no governed resend for recurring failures.
- The multi-level approval chain is hard to maintain. Changing who approves what by cost center and category means scattered rules; every organizational change is handled by hand.
- The audit trail is rebuilt from emails before each audit, instead of being a by-product of the flow.
The perceived option is to stay on email and spreadsheets (no trail) or build a custom development (risky, long). What is missing is to implement a governed budget flow over the Operational Graph —from a clean base, with the approval model and master data as part of the graph.
The EAFlow solution
Budget Approval Workflow is a CPG accelerator built on the cross-cutting Workflow solutions and the common Operational Graph layer of EAFlow Platform, with service integration to the financial ERP, operating alongside the client's ERP —without extending its core or replacing it. The validation covered, over a new implementation from a clean base:
- A new implementation over EAFlow, not a migration from a previous tool. The request object, the approver matrix and the cost-center, account and category catalogs were modeled over EAFlow from a clean base, without rewriting an inherited process.
- Master data as graph entities. Cost centers, operating accounts, categories, asset class, classification and the approver chain live in the Operational Graph, not in separate spreadsheets.
- Form by type (OPEX/CAPEX) with no hard-coded rules: the form changes by reading the graph.
- Configurable multi-level approver chain by cost center and category, with an optional Informed role. Every transition is signed by its author, with a pending-task banner and an audit trail walkable over the graph.
- Service integration to the financial ERP. On approval, the bus pushes the request to the ERP via an authenticated service, without extending the core or breaking the upgrade path.
- Rework and exception classification with human control. If the integration fails, the case is flagged for reprocessing; errors are classified (missing data, evidence, amount change, budget adjustment) and the resend of known recurring cases goes through a human owner.
- Audited master-data configuration (CRUD without reprogramming the flow) and governed querying over the budget corpus, citing the request and the corresponding node, with human control on every action.
The scope is confirmed in discovery (cost centers, approver chain, categories, ERP APIs and permissions). The accelerator operates alongside the ERP, without extending its core or replacing it.
What was validated
The experience ran by implementing a budget flow over EAFlow from a clean base and operating it over the Operational Graph. The finance team walked the full cycle: process modeling over the graph, master data as entities, form by type, multi-level approver chain with a per-transition audit trail, service integration to the ERP, rework classification with human control and audited master-data configuration.
Demonstrated capabilities
- Operational Graph as the common context base.
- Budget process modeled over the graph from a clean base.
- Master data (cost centers, accounts, category, asset class, approver chain) as graph entities.
- Form by type with no hard-coded rules.
- Configurable multi-level approver chain with a per-transition audit trail.
- Service integration to the financial ERP, without extending the core.
- Rework and exception classification with human control.
- Audited master-data configuration and governed querying over the budget corpus.
Observed outcome
The budget workflow moved from "living in email and spreadsheets" to operating over the graph, connected to its cost center, category and approval chain. Master data stopped living in parallel spreadsheets; the approver chain is configured by cost center and category without touching code; the ERP integration is done by service without extending the core; rework is classified with human control; and the audit trail stopped being rebuilt from emails and became a by-product of the flow.
The validation confirmed that the accelerator governs the budget workflow over the client's operational graph, integrated to the ERP by service.
Why it matters for other organizations
The pattern repeats in food and consumer companies with CAPEX/OPEX budgets managed over email and spreadsheets: the process works but leaves no trail, master data lives apart and the ERP load is manual. Implementing a governed flow over the Operational Graph —without replacing the ERP, integrating by service and adding rework classification— reduces rework and restores traceability.
Starting with the budget workflow is also a low-risk entry point: the same Operational Graph that holds the requests and the master data later holds processes, inventory, change impact and control assurance.
How it scales — related solutions
The budget workflow is reused over the same Operational Graph:
- Toward other CPG accelerators HR Shared Services — Negotiated Offboarding and Supplier Service Desk — Shared Services CPG
They share the workflow + master data + service integration pattern over the graph, and can coexist in the same tenant.
- Toward processes Process Knowledge
The budget process connects to the modernized process corpus.
- Toward the inventory Live IT Inventory
The applications and the integration bus connect to the portfolio inventory.
- Toward change Change Impact
A change in the approval chain or in master data is assessed by impact over the graph before being applied.
- Toward vendors and risk Vendor, SLA & Contract Intelligence and Risk & Control Assurance
CAPEX budget tied to vendors and contracts, and the process controls (segregation of duties, approval limits), enter the model.