Financial ERP vs operational layer
Why the ERP doesn't run your HORECA purchasing operation
Your ERP books and consolidates; the operational layer runs purchasing, receiving and stock.
The ERP isn't built to run daily HORECA operations
In mature groups the customer doesn't start from chaos: they already have an ERP, a POS/PMS and, often, a purchasing office negotiating. The realization is that the ERP —the financial core— isn't the tool to run daily HORECA operations: a product master by supplier and format, equivalences, units, recipe costing, delivery note OCR, goods receipt and stock by point of consumption. That complexity shouldn't be forced into the financial ERP; it belongs in a specialized operational layer.
Unmanageable master data
The same product multiplies by supplier, format, brand and legal entity. The ERP master data grows out of control and no one sees what is actually being bought.
Fragile recipe costing
Every supplier or format change breaks the recipe costing. Maintaining it inside the ERP is a permanent development project.
Operational roles with no tool
Kitchen, goods receipt and the storeroom need something simple to order, receive and validate. The ERP doesn't fit their logic and they end up bypassing it.
Three layers, each doing its job
Strategy negotiates, the operational layer executes and the ERP books the accounts. The problem isn't the accounting software: it's the missing layer that turns purchasing policy into real execution at every location.
Strategy · Purchasing office
Negotiates supplier, rate and catalog. Rationalizes the master data. Defines the policy, but doesn't ensure it's followed at each location nor validate goods receipt.
Operational layer · Controliza
Purchasing product, order, goods receipt and delivery note, recipe costing, stock and operational reporting. This is where product, quantity and price deviations are caught.
Accounting · ERP
Validated invoice, aggregated accounting entry, legal entity, dimension and cost center. It receives the data already clean and ready to book.
The negotiated saving only becomes a captured saving when each location buys what's approved, receives what was ordered and validates price, quantity and product at goods receipt. Negotiating better doesn't guarantee saving more: the saving is captured in execution. For the hotel case, this takes shape as financial control of F&B purchasing from order to payment.
Discover which part of the operation should leave your ERP
Request a Free DemoFrequently asked questions about ERP and the operational layer
Why isn't the ERP the right tool to manage HORECA purchasing?
Because the ERP is designed to book and consolidate the accounts, not to run daily operations: a master by supplier and format, equivalences, recipe costing, delivery note OCR, goods receipt and stock by point of consumption. Forcing that complexity into the ERP generates expensive development and unmanageable master data. That operation belongs in a specialized operational layer.
What is an operational layer and how does it differ from the ERP?
It's the software that executes and controls the purchasing operation at each location —order, goods receipt, delivery note validation, stock and analytical data— and returns clean, bookable data to the ERP. The ERP remains the financial core; the operational layer is where purchasing actually happens.
Does Controliza replace my ERP?
No. Controliza complements the ERP: it doesn't touch accounting or consolidation. It runs the purchasing operation and delivers to Finance the entry with the dimension it needs. Your ERP consolidates and books the accounts, your purchasing office negotiates, Controliza executes.
Why not develop purchasing operations inside the ERP itself?
Because the cost and fragility are high: the master data grows out of control, recipe costing breaks with every supplier change and operational roles need a simple tool the ERP doesn't offer. The negotiated saving is lost if execution isn't usable.
