A three-outlet coffee chain asked me to "put Acumatica on the tills." I had to talk them out of it in the first meeting. Acumatica is not a point-of-sale system, and it has no ambition to be one — there is no till screen, no receipt printer driver, no tender workflow anywhere in the standard product. What Acumatica is very good at, for a cafe business, is everything behind the counter: multi-location inventory, recipe-based costing for what a flat white actually costs to make, and consolidated financials across outlets. Getting the boundary right between the till and the ERP is the entire project.
The POS integration is a bridge, not a feature request
Acumatica does sell "Acumatica Point of Sale, powered by Heuristyc," but it is explicitly positioned for counter/wholesale sales scenarios rather than a hospitality quick-service register, and it is not what most cafes already running Square, Toast, or a regional POS want to rip out. The realistic architecture for an existing cafe is: keep the POS the baristas already know, and build a nightly (or near-real-time) sync of sales summaries and inventory depletion into Acumatica via the contract-based REST API, landing as a summarized AR/cash transaction and an inventory issue against the recipe's ingredients — not a line-by-line replica of every till transaction, which would be both pointless and a performance problem.
Sold item (from POS): Flat White 12oz
Maps to BOM: BOM-FLATWHITE-12
Components: Espresso shot x2 (from ROASTED-COFFEE-KG)
Milk 200ml (from MILK-FRESH-L)
Nightly job: POS sales summary -> Acumatica REST API
-> Inventory Issue against BOM components
-> AR cash transaction for the day's till totalWhy a cafe needs BOMs at all
The thing that makes this a genuine Manufacturing-flavoured build rather than plain Distribution: a cafe does not sell milk and coffee beans, it sells a flat white, and the only way to know true margin — not "revenue minus COGS estimated by category" but "this exact drink costs 43 shillings in ingredients" — is a BOM-based cost rollup per recipe. I typically enable light manufacturing functionality (or use inventory kits for the simplest cases) specifically for this costing purpose, even though there is no physical production floor. It feels like overkill until the client asks why oat-milk drinks are quietly losing money at current pricing, and the BOM rollup answers it in one report instead of a guess.
Acumatica's simpler Kit Assembly feature can substitute for a full BOM when a "recipe" is a fixed, non-variable bundle. It falls short the moment recipes have substitutions (oat milk vs regular, extra shot pricing) or waste factors (spilled shots, over-pour). At that point a real BOM with a routing, even a trivial one-step routing, is worth the extra setup because it gives you variance reporting kits do not.
What Acumatica is unambiguously right for
Where this stops being a compromise and becomes a clear win: three outlets each running their own POS produce three separate pictures of the business unless something consolidates them. Acumatica's multi-branch structure, with each outlet as a branch sharing one chart of accounts, gives ownership a same-day consolidated P&L instead of three spreadsheets reconciled by an accountant on the 5th of the following month. That consolidation is the actual value proposition for a cafe chain — the POS bridge is the price of admission to get there.
Wrapping up
Do not try to make Acumatica be the till. Let the POS the staff already use stay, bridge it via REST API into recipe-based inventory depletion and summarized cash transactions, and spend the real engineering effort on BOM-based recipe costing and multi-branch consolidation — that is where the ERP earns its keep for a cafe business.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.