POS (Point of sale) systems

Workflows > Usecase > eCommerce, POS and payments > POS

Use case: This use case involves integrating POS systems with PowerOffice to manage daily cash sales and credit sales through simplified reconciliations, invoice handling, and accurate reporting for effective financial management.

Important supplementary information:

Cash sale

Base functionality for any approved POS system used by companies with retail shop's or restaurants (as the typical examples). Daily cash sale (by the accounting definition, not to be confused with physical cash payment) are registered in the POS system, and the end of day reconciled sale and incoming payments are to be transferred to PowerOffice.

The best practice is to post a daily cash sales using a CashJournal and the CashVoucherPosting endpoint . The most common approach is to keep the level of detail as simple as possible, transferring sum gross amounts per general ledger account, per vat code. All lines transferred to PowerOffice should be gross amounts (including vat) an set with the relevant standard SAF-T vat code, as PowerOffice handles the vat transactions when the voucher is posted.

An simple example for a restaurant, with arbitrary accounts for the sake of the example:

Let's assume that the restaurant had a Friday night sales total of 18 650 with the following result:

  • Food in-house: 12500 NOK, including 25% vat

  • Food take-away: 1150 NOK, including 15% vat

  • In house sale of beer: 2500 including 25% vat

  • In house sale of soda: 2500 including 25% vat

  • 5000 NOK was paid with physical cash

  • 13 650 NOK was paid with Visa card

    By the end of the day, the POS system integration with PowerOffice will post the following via our api:

  • Debit account 1901 "Cash", amount 5000, vatcode 0

  • Debit account 1910 "Visma", amount 13650, vatcode 0

  • Credit account 3000 "In house food", amount 12500, vatcode 3

  • Credit account 3001 "Take-away food", amount 1150, vatcode 31

  • Credit account 3002 "Beer", amount 2500, vatcode 3

  • Credit account 3003 "Soda", amount 2500, vatcode 3

With the simple example above as a baseline, this can be expanded with more information if needed and the use case calls for it. This includes dimensions such as departments, locations or any custom dimensions. Transactions can also be split on specific products, but then require a sync/set up of products that might be unnecessary in the terms of case sales isolated.

Credit sale

Some POS systems support orders and invoicing, allowing for end customers to make purchases and be invoiced for payment at a later point in time (credit sales). There are two main approaches for integrating this:

  • POS system can create and send invoices: The approach will be to transfer and post the invoice information to PowerOffice, using the OutgoingInvoiceJournal endpoint .

  • The POS system cannot create and send invoices, only handle order information and rely on an external invoice system: The approach will be to transfer sales orders to PowerOffice , with the option of creating and sending invoices via api.

Regardless of approach, it is important that credit sale is kept separate from the cash sale transfer (sales not duplicated) in the integration.

If customer payments of invoiced need to be reported from PowerOffice back to the POS system, consider the approaches in this article depending on the details needed.

POS FAQ


Q: What if the client have multiple sales points

A: When we refer to the PowerOffice client, we refer to the legal entity using PowerOffice. Often we see cases of the client having multiple (physically) distinct sales points separated by department or locations. Note that the clientkey in the client credentials context apply for the client - ie the legal entity using PowerOffice. In this "system to system" approach, we assume that the POS back office solution is communicating with our api and the client - regardless of whether the client have multiple instances of the POS system for their different sales points. This should be handled by your back office, pushing end of day sales either summarized (but split by department etc) or transferred as one end of day cash journal per sales point.

Q: What of cases where the credit sale (invoice) is paid in the store

A: Sometimes a customer is invoiced for a purchase, but choose to pay the invoice along with another purchase done when revisiting the store.

If the POS system allow for and support this case, the payment transaction should be handled as described below regarding "transferring payment events to PowerOffice". Only the payment event should be handled, assuming that the sale is already posted to PowerOffice when the customer was invoiced. The payment event in itself (debit account <payment type>, credit customer ledger) can be handled with an isolated voucher transfer to PowerOffice, or part of the end of day cash voucher transfer. The best practice if this is a common case for your integrations, is to use <customMatchingReference> on sales orders or invoices transferred to PowerOffice, and then use the exact same and specific invoice <customMatchingReference> on the payment transaction.