Skip to main content
Every point-of-sale system closes with a Z report. That report is a summary of everything sold, refunded, and paid at a till since the last closure. For many small and medium businesses, someone still types that Z report into accounting by hand, one line at a time, for every location. Connecting a POS system to accounting software removes that manual step. Sales and payments post to accounting as soon as a register closes, consistently, for every location. The result: less time spent re-entering the same numbers, fewer reconciliation errors, and an up-to-date view of turnover and cash across every location. What does that connection mean in practice? What gets created in the accounting software? What has to be configured before it can run? What can you expect from it? This use case tackles those questions. For the broader business case (compliance, real-time visibility, fewer reconciliation errors), see Why POS software needs integrations on the Chift blog.

​
The objects involved

​
Core concepts

​
Orders and closures

An order is one sale. A closure is not a separate record sitting next to the day’s orders. It is the day’s orders themselves, bundled together and finalized the moment a till closes. That bundling is what “Z report” actually means: every order confirmed since the last closure, grouped into one. Not every POS groups them the same way. Some POS systems produce that closure themselves, as a genuine record the instant the till closes. In that case the orders inside are safe to book right away. Others have no such concept at all: nothing in that POS ever states that a day is truly finished. Either way, once a day counts as closed, the entry posted to accounting is built from its full set of orders, not from one order at a time. That is also why the entry in the example above shows totals for the day, not a line per sale.

​
Locations

A POS can operate a single till or several. When more than one location is involved, every closure needs to carry information about which location it came from. Otherwise, sales from different tills get mixed together in the accounting. The location can be inferred automatically from how the connection itself is scoped, one connection per till. It can also be attached explicitly to each closure, when a single connection covers several tills at once.

​
Payment methods

Payment methods matter to accounting because they determine where the money actually sits after a sale. Cash stays in the till until someone banks it. A card payment moves through a payment processor and typically settles a few days later, sometimes minus a fee. For a sale to book correctly, every payment method used at the till needs to point to the account that reflects where that money goes. Payment methods can also change over time, for instance when a POS adds a new digital wallet. Your end-user should revisit this mapping occasionally, rather than treat it as a one-off task.

​
What happens in accounting

The accounting system creates one entry per closure. It has a simple shape: a debit line for every payment method that collected money, a credit line for revenue per product category (excluding VAT), and a credit line for VAT per tax rate. Chift builds this entry from the closure data, once your end-user has configured a few settings. Those settings are covered further down.

​
Example: a retail store’s Z report

A store’s Z report for the day totals 200.30 EUR of sales: 105.50 EUR of food (100.00 EUR excluding VAT, at the 5.5% rate) and 94.80 EUR of drinks (79.00 EUR excluding VAT, at the 20% rate). Of the total, 150.30 EUR was paid by card and 50.00 EUR in cash. *Illustrative, French-chart-of-accounts-style numbers, shown to make the example concrete. Actual account numbers depend on the country and the chart of accounts in use. Total debits (200.30) equal total credits (200.30).

​
What gets configured

Before a POS-to-accounting connection can produce its first entry, your end-user makes a small set of choices, once. At a high level:
  • A journal. The ledger where all of a business’s POS closures get recorded.
  • An account per payment method. Cash, card, and any other method the POS supports, each pointing to where that money actually sits.
  • How revenue gets split. Your end-user chooses the level of detail: everything in a single account, one account per product category (food versus drinks, for instance), or one account per VAT rate.
  • An account per VAT rate. Each tax rate the business charges needs its own account to receive the VAT collected on it.
  • A few edge cases, when they apply. Tips, which belong to staff rather than to revenue. Items given away for free, which shouldn’t inflate revenue. Discounts, which reduce revenue but aren’t a payment method.
None of this needs to be fully mapped before a business can go live. A fallback covers anything not yet configured. But this is the shape of what a business owner or their accountant will be asked to decide.
Who configures what. Your end-user, or their accountant, makes the accounting-specific choices below (which journal, which account, how revenue is split). They know their own books; you never make these choices. Your end-user makes these choices once, in a mapping screen at setup. You build that screen with the Unified API, or Chift provides it with a Sync (see What you build). The rest of this article describes those choices at a high level, so you know what is ahead, not because you need to make them yourself.

​
What you build

The choices above are always your end-user’s to make, never yours. What you build is the integration around those choices, and how much of it you build depends on how you connect to Chift. With the Unified API, you build it yourself:
  • a mapping screen where your end-user selects their journal, the account for each payment method, how revenue is split, and the VAT account for each rate (you fetch the options from their accounting software and present them);
  • send logic that posts each closure to accounting once it is final.
With the POS Sync, Chift builds it for you. The mapping screen and the synchronization run on Chift’s side. Your end-user makes the same choices through Chift’s interface. You build neither the screen nor the booking logic.