Hospitality software integrations: the questions to ask before buying

Hospitality software integrations are sold on the strength of the logos. Lightspeed, Square, Xero, Sage — the partner logos appear on the website, the sales deck references them, and the implication is that data flows cleanly between systems.

The logos tell you that a technical connection exists. They do not tell you what the connection does, how reliably it does it, or whether it transfers the specific data your operation needs. Understanding what API integration actually means helps you evaluate the claims behind those logos.

These are the questions to ask before the contract is signed.

For POS integrations

What data does the integration receive, specifically?

The range of possible answers spans from "total daily revenue" to "transaction-level data including category, payment method, covers, and time-of-sale." Total revenue is useful for a rough cash-up check. Category-level revenue is necessary for meaningful GP calculation. Transaction-level data enables detailed analysis.

Ask the vendor to describe specifically what their POS integration receives. If the answer is vague ("we get all the relevant sales data"), ask again for the specific fields.

When does the data transfer happen?

At session close is the ideal. On a fixed daily schedule is common. On demand, when the operator initiates a sync, is effectively manual. Understanding the timing tells you when the data will be available and whether any human action is required.

What happens when the connection fails?

Every integration fails occasionally. The important questions are: how does the system detect the failure, how quickly, and how does it communicate it to the operator? What happens to the data during the outage period — is it retrieved when the connection restores, or is the gap lost?

Is this integration listed in the POS vendor's partner directory?

Some POS vendors maintain partner directories or certification programmes for third-party integrations. A listed integration has usually been tested by the POS vendor. An unlisted integration has not. Neither is a guarantee of quality, but the distinction is worth knowing.

For accounting integrations

Does the integration post journals or just export files?

A genuine accounting integration posts journal entries to the accounting system programmatically, via the accounting API. A file-based integration exports a CSV or similar file that the operator imports manually into the accounting system. The second approach requires an operator action and inherits all the risks of manual import.

At what level of detail does the journal post?

Category-level revenue posted to separate nominal codes — food revenue to one code, drinks revenue to another — enables category GP calculation in the accounts. A single total revenue journal posted to one code does not.

The level of detail in the journal should match the level of detail you need in the accounts. Confirm this specifically before assuming the integration provides it.

Does the integration handle VAT correctly?

VAT handling in hospitality is not straightforward. Different items carry different VAT rates. Some items are zero-rated, some are standard-rated, and the rates may vary based on how the item is served. Confirm that the integration posts VAT correctly for the specific product mix of the operation.

Does it handle credit notes?

When a supplier issues a credit note — for a short delivery, a price error, a returned product — does the integration push this to the accounting system automatically, or does it require manual entry?

For inventory-related integrations

Does supplier invoice data flow through the system, or is it entered manually?

An inventory system where supplier costs are entered manually requires someone to update product costs when prices change. A system that connects to invoice processing and updates costs from approved invoices reflects current pricing automatically. Confirm which approach the system uses.

How does the system handle multi-location stock?

For operations with multiple sites, each with their own stock, confirm that the system tracks each location separately while producing a group view. Confirm also that the transfer of stock between locations (central kitchen to site, or between sites) is handled within the system.

The trial question

After gathering the above information, the most useful next step is a trial. Not a demo — a trial with your own data, your own POS, and your own accounting system.

An integration that works in the vendor's controlled environment is not confirmed until it works in your specific environment. POS API versions, accounting system configurations, and data formats vary enough that genuine testing with your systems is the only reliable evaluation. If you have encountered software that looked good in the demo but failed in practice, a trial with real data is the test worth insisting on.

Hops publishes specific integration details for all supported POS and accounting systems. The questions above are ones we welcome, because the answers are specific and verifiable. Ask them of any platform you are evaluating.