EAFlow
Book demo

ANONYMIZED CASE · CPG

CAPEX/OPEX budget governed over the graph, integrated to the ERP without touching the core

A leading consumer-packaged-goods organization validated Budget Workflow — CAPEX/OPEX + ERP by migrating its budget solution from a legacy low-code platform to EAFlow: form by type with master data from the graph, multi-level approver chain by company code and cost center, service integration to the financial ERP and a governed reprocessing agent for failed integrations —preserving the approval model.

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 touching the core, with the approval chain and the audit trail preserved.

See the budget-workflow solution Operational validation

The challenge

In a consumer-packaged-goods organization that manages its CAPEX/OPEX budget with a solution built on a legacy low-code platform, the pattern repeats: the process works, but it lives trapped.

  • The approval process is locked inside the legacy low-code platform. The approval model, master data and forms sit in proprietary structures; license and maintenance cost grows and the platform upgrade is risky.
  • Master data lives in parallel spreadsheets or in the legacy platform itself. Company codes, cost centers, accounts, vice presidencies, asset class and approver chain are not connected to the rest of the operational model.
  • The ERP integration is fragile. Extensions on the ERP core, or point-to-point integrations from the legacy platform, break the upgrade path and force rework on every version change.
  • Failed integrations are reprocessed by hand. When an approved request does not reach the ERP, someone reprocesses case by case, with no error classification and no automatic reprocessing for known recurring failures.
  • The multi-level approval chain is hard to maintain. Changing who approves what by company code and cost center means touching hard-coded rules; every organizational change is a technical project.
  • The audit trail is rebuilt from emails before each audit, instead of being a by-product of the flow.

The perceived option is to rebuild the process from scratch (risky, long) or stay on the legacy platform (a growing bill). What is missing is to migrate the budget solution to an accelerator over the Operational Graph, preserving the approval model and the master data.

The EAFlow solution

Budget Workflow — CAPEX/OPEX + ERP is a CPG vertical accelerator built on the cross-cutting Workflow solutions and the common Operational Graph layer of EAFlow Platform, with integration to the financial ERP by maturity, operating alongside the client's ERP —without extending its core or replacing it. The validation covered, over the client's budget solution:

  • Migration from the legacy low-code platform preserving the business model. The main object (hundreds of fields), the approver matrix (thousands of records), and the company-code, cost-center, account and asset-class catalogs were migrated to EAFlow preserving the approval model —without rewriting the process from scratch.
  • Master data as graph entities. Company codes, vice presidencies, directorates, cost centers, operating accounts, product categories, logistics centers, asset class and classification live in the Operational Graph, not in separate spreadsheets.
  • Form by type (OPEX/CAPEX) and by company code with no hard-coded rules: the form changes by reading the graph.
  • Configurable multi-level approver chain by company code and cost center, 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 (clean-core). On approval, the bus pushes the request to the ERP via an authenticated service. The integration is agnostic across financial ERP versions —ECC and S/4 in coexistence—, and clean-core compatible: it does not extend the core or break the upgrade path.
  • Governed reprocessing agent with human-in-the-loop. If the integration fails, the record is flagged for reprocessing; the agent scans the queue, classifies the error (exchange rate, conversion field, incompatible status, annual budget exceeded by master data) and automatically resends only the known recurring failures, while new cases go through a human owner.
  • Continuous improvement of master data with audited CRUD 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 (company codes, ECC + S/4 coexistence where applicable, cost centers, approver chain, ERP APIs and permissions). The accelerator operates alongside the ERP, without extending its core or replacing it, and without necessarily replacing the legacy low-code platform in a single engagement.

What was validated

The experience ran by migrating the client's budget solution from the legacy low-code platform to EAFlow and operating it over the Operational Graph. The finance team walked the full cycle: business-model migration preserving structure, master data over the graph, form by type and by company code, multi-level approver chain with a per-transition audit trail, clean-core service integration to the ERP, a classified reprocessing agent with evidence of reprocessing managed over the approver matrix, continuous improvement with audited CRUD and governed querying —with a side-by-side comparison between the solution on EAFlow and the solution on the legacy platform.

Demonstrated capabilities

  • Operational Graph as the common context base.
  • Business model migrated from the legacy low-code platform preserving structure.
  • Master data (company codes, VPs, cost centers, accounts, asset class, approver chain) as graph entities.
  • Form by type and by company code with no hard-coded rules.
  • Configurable multi-level approver chain with a per-transition audit trail.
  • Service integration to the financial ERP, clean-core (ECC or S/4 in coexistence).
  • Governed reprocessing agent with human-in-the-loop: automatic for known recurring failures, manual for new cases.
  • Continuous improvement with audited CRUD and governed querying over the budget corpus.

Observed outcome

The budget workflow moved from "living trapped on the legacy platform" to operating over the graph, connected to its company code, cost center and approval chain. Master data stopped living in parallel spreadsheets; the approver chain is configured by company code and cost center without touching code; the ERP integration is done by service without extending the core; failed integrations are classified and, for known recurring failures, automatically resent with human control for new cases; 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 clean-core service.

Why it matters for other organizations

The pattern repeats in CPG organizations with CAPEX/OPEX budgets on legacy low-code platforms: the process works but stays locked in, master data lives apart and the ERP integration is fragile. Migrating the solution to an accelerator over the Operational Graph —preserving the approval model, integrating to the ERP by service without touching the core and adding governed reprocessing— reduces the risk of the migration and of day-to-day finance.

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 migrated budget workflow is reused over the same Operational Graph:

Assess my use case See the budget-workflow solution