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

​
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 the revenue earned (excluding VAT), and a credit line for the VAT collected on that revenue. 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 214.60 EUR of sales, including 35.60 EUR of VAT. Of that, 142.35 EUR was paid by card and 72.25 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 (214.60) equal total credits (214.60). If sales span more than one VAT rate, or revenue is split by category, the entry carries one revenue credit line per rate or category instead of one. The underlying logic stays the same.

​
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 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. As a single total, by product category (food versus drinks, for instance), or by VAT rate.
  • 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. The accounting-specific choices below (which journal, which account, how revenue is split) are made by your end-user, or their accountant, who knows their own books. They are never made by you. 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 the mapping screen and the logic that sends each closure to accounting once it is final. With the POS Sync, Chift provides both. The mapping screen and the synchronization run on Chift’s side, and you build neither.