POS, inventory, and finance: three systems that need to talk

The POS records what was sold. The inventory system records what was consumed. The finance system records what it cost. Three separate systems, each capturing a different slice of the same business reality.

When these three systems do not talk to each other, the operator has to do the talking for them: exporting data from one, entering it into another, reconciling the differences, and assembling the GP figure from parts that were not designed to fit together.

When they do talk — automatically, accurately, without manual transfer steps — the GP figure emerges from the operation itself, not from the assembly exercise.

Why each system needs the others

The POS needs inventory context. Without knowing the cost of what was sold, the POS revenue figure is a top-line number. It does not tell you what the sale contributed to margin. The inventory system provides the cost context that turns revenue into GP.

The inventory system needs POS data. Without knowing what was sold, the inventory system can only report consumption in total: what left the stock, without a basis for comparison. The POS data provides the theoretical consumption — what should have left, given what was sold — that makes variance analysis between POS and inventory possible.

The finance system needs both. The accounting system needs the revenue from the POS (for the journal entry) and the cost from the inventory and invoicing process (for the cost of goods entry). Without both, the P&L is incomplete. The GP figure cannot be calculated.

Each system is more useful with the data from the others. All three together produce something none of them can produce alone.

What the conversation between them looks like

In a properly connected system, the data exchange is continuous and automatic.

POS to operational platform. When a session closes on the POS, the sales data — category-level revenue, payment method split, covers count — flows to the operational platform. This happens automatically, not via a manual export.

Operational platform processes costs. Supplier invoices arrive in the operational platform, are processed through OCR, reviewed by the operator, and approved. Each approved invoice adds cost data to the cost-of-goods calculation, allocated to the correct category.

Operational platform processes stock. Stock takes are completed in the operational platform, digitally, and the results update the inventory position immediately. The variance between theoretical and actual consumption is visible.

Operational platform to accounting system. The sales journal — revenue by category, payment methods, VAT — posts to the accounting system automatically, typically at the end of each day or week. The cost journals — coded invoice costs, by category and period — post when invoices are approved.

At each point, the data moves automatically. No manual transfer. No transcription. The operator's interaction is the review and approval steps that require human judgement — not the data entry steps that do not.

The category mapping is the critical setup

The connection between the three systems depends on a category structure that is consistent across all of them.

The POS organises sales by category (food, drinks, merchandise). The inventory system tracks stock by category (dry goods, produce, beverages). The accounting system records costs by nominal code (food, beverages, other COGS).

For the GP calculation to be meaningful — category food GP and category drinks GP, not just a blended total — these category structures need to be aligned. The same category definition must flow through from POS sale to inventory cost to accounting code. The guide to connecting POS to accounting software covers this mapping in detail.

This alignment is configured once, during setup. Done correctly, it runs automatically. Done incorrectly, the category GP figures are wrong from the start — the right total, the wrong split.

The compounding value over time

The value of the three-system connection compounds over time. This is what the hospitality tech stack that actually works is built on.

In the first month, the value is operational: the cash-up is faster, the weekly GP is available without manual assembly, the invoice backlog reduces.

Over six months, the value is informational: consistent, comparable data across multiple periods creates trend visibility. The GP this week can be compared to the GP from the same week in the prior quarter, with confidence that the methodology is consistent.

Over a year, the value is strategic: the data history supports decision-making at a level that periodic manual GP calculations cannot. Menu changes can be evaluated against pre-change performance. Supplier price movements can be tracked across the year. The relationship between operational decisions and financial outcomes becomes visible.

Hops is the operational layer that connects the POS, inventory, and accounting system. The conversation between the three systems happens automatically. The GP figure reflects what is actually happening, in real time, without the manual assembly exercise.