E-commerce considerations

Intro and important definitons

The source of this section is the NGAAP legislation including the GBS16-Internettsalg dokumentation, the SAF-T requirements, and this article from Regnskap Norge .

The timing of events are important in terms of the rules that apply for a given webshop case. In accounting terms, a sale does not usually occur until the delivery of the service/product takes place.

The method of payment in a webshop, have no effect at all on the definitons below and the sales events in itself. Neither does any outsourcing of the invoicing process*, the use of factoring or services like sale of invoices.

Type of sales in the context of the legislaton

• Cash sale: Delivery of service/product and the payment takes places simultaniously, at a physical location. The method of payment does not matter, the point is that delivery and payment takes place at the same point in time. Cash sale have special regulations and reqirements. Sale is booked at the time of delivery. Point of sales (POS) systems that comply with cash sale legislation is required, with end-of-day reporting and z-reports as required documentation of the sale.

• Internet sale: Delivery of service/product and payment occurs at the same point in time, but it need not be at a physical location (i.e. downloading an app or paying for a car parking service). Sale is posted (accuonting wise) at the time of delivery. Internet sales are essentially cash sale, but a special rule stipulates that internet sales are not considered cash sales by definiton.

• Credit sale: The usual/typical invoice usecase. A a weborder is placed, and a regular invoice is issued at the time of delivery of the service/product. The sales is posted (accounting wise) at the invoice date. The customer pays the invoice at a point later in time (given by the payment terms of the invoice).

• Payments in adwance: A customer orders and pay for a service/product, but the delivery takes places later. This is by definiton not a sale, it is an "payment-in-adwance" event. Normally, the sale should not be posted (accounting wise) until the actual delivery of the service/product takes place, and when posted, the sale should be documented as an invoice.

As a general note, the points above can be summarized as the following:?

If the sale is not considered cash sale, the sale follow the documentation requirements of invoices, and should be posted via the customer ledger upon delivery of the product/service.

The sale and the payment are two different events, and PowerOffice are designed so that the sale (invoice) and payment (bank/cash voucher) are two separated accounting events.

*If the sale follow the general rules for invoice documentation, it is important to note that the rules apply even when the invoice process is outsourced to a third party. The seller is responsible for issuing the correct and formal accounting documentation, and using order information or third party invoice information might not comply with the requirements.

E-commerce considerations in practice

1. Clarify the type of sale the case(s) is subject to and what rules apply to it

2. If invoice documentation is required for the case, assess whether the webshop provide sufficient documentation or if PowerOffice should be used to generate sufficient invoice documentation

   • If the webshop provide sufficient invoice documentation, the best practice is to post sales vouchers to PowerOffice. Consider the level of details required for SAF-T reporting and the considerations in [this section]

   • If the invoices need to be (re)generated in PowerOffice*, the case is to transfer sales orders to PowerOffice which will then be invoices and posted in the process. SAF-T requirements shoud be in compliance in this approach, as all sales information is registered in PowerOffice.

3. Regardless of point 2, handle the payments as separate events. Payment transactions can be batched, the typical use case is to post all payment events as transactions in one bank type voucher per day.

Example of the case:

1. Ordered car shampoo from a webshop.

2. Used <Some payment provider> checkout.

3. Received invoice from <some payment provider> when the product was shipped, to be paid

4. Also received invoice from the company behind the webshop (the actual seller). This invoice is clearly watermarked with "do not pay", as the payment is handled with <some payment provider>.

Point 4 above occurred because the <some payment provider> invoice, in this case, could not be considered as sales documentation from the sellers perspective in their bookkeeping. The seller needed to issue their own sales documentation in compliance with the norwegian bookkeeping act.