Developer Info

Guidelines and best practices

Compliance with accounting rules


Keep in mind that you integrate with an accounting system. Not all workflows affect the accounting directly, but if your workflow does, you are responsible for integrating in a way that do not violate our customers compliance of the accounting rules and regulations. We do not offer accounting advice as part of our api support or in our initial dialogue with parties integrating with PowerOffice. Whenever possible, you should always involve a pilot customer and their accountant if you have questions regarding the accounting effect of your particular workflow. We can, however, offer general insight and highlight issues - we are happy to be involved in processes that include accountants and customers.

An example of an area with particular considerations, is the requirements for SAF-T reporting and especially within the domain of e-commerce. These are not considerations specific to PowerOffice, but a general aspect of SAF-T requirements and e-commerce.

Disclaimer

We reiterate that PowerOffice AS do not provide accounting services. PowerOffice AS will not be held legal responsible for any guidelines or adwice given to integrating parties, in terms of how an integrated data workflow affect the accounting in any given framework of legislation. Allways discuss accounting usecases and best practices with an accountant, before implementing a live solution.

The purpose of this article is to highlight the considerations that need to be made in terms of accounting legislation and practices. The information in this article is derived from the current NGAAP framework, with the rules and "best practice statements" within this frame of work. PowerOffice AS are not responsible for keeping this information updated.

Backend systems integrated with PowerOffice, and SAF-T

Dictionary and intro

  • The information below is based on this FAQ from The Norwegian Tax Administration

  • We refer to The Norwegian Bookeeping Act and The Norwegian Bookkeeping Regulations using the term "NBL".

  • Our customer is referred to as the client

  • The context of the legislation is from the clients point of view

General information from The Norwegian Tax Administration

The detailed requirements for account specifications and customer and supplier specifications are outlined in the NBL ? 3-1 first paragraph numbers 2, 3, and 4. All entries must be included in the specifications in an orderly manner, with documentation date and documentation reference. Account specification and customer and supplier specifications are subject to the requirement for SAF-T. It is permissible to use totals in the account specification if transactions and other accounting dispositions are presented individually and summarized in an underlying specification, and are verifiable against the totals, in compliance with NBL ? 3-1 fifth number.

If the recorded information is stored in a backend system, the backend system becomes part of the accounting system, and the recorded information in the backend must be kept electronically available for 3.5 years after the end of the fiscal year. An example could be that the customer specification is kept in the backend invoicing system, while the account for receivables in the account specification only shows aggregated numbers (per month, maintenance period, etc.). Documentation date, documentation reference, customer code, amount, etc. for each transaction can be found only in the backend invoicing system, which constitutes a sub-specification to the account specification.

Sub-specifications are considered part of the account specification and are included in the requirement for SAF-T. Customer and supplier specifications kept in a backend are subject to the requirement for SAF-T.

In summary, all transactions between the client and it's customers (and suppliers), must be reported in the SAF-T format on a transaction level. In practice, this means that every sale to a customer or purchase from a supplier must be reported per invoice/purchase in the SAF-T reports. This can be from PowerOffice, or supplemented to PowerOffice by a SAF-T report from a backend system. It is not sufficient to only report summary posts (Batch posts) in PowerOffice, without any supplementary SAF-T report.

Addressing this in practice


There are 2 ways to handle this requirement for the backend system that integrate with PowerOffice. The options will depend on how the backend system want to record transactions in the accounting system, and whether or not the backend system can provide SAF-T reporting.

Alternative 1:
Transactions are transferred per transaction (invoice) and a voucher is created in the accounting system per sale or purchase. If provided with sufficint details to PowerOffice, the SAF-T reports form our system will satisfy the reporting requirement of the accounting system as a whole.

Alternative 2:
The backend system transfer vouchers to PowerOffice with summary posts (batch posts) for daily, weekly, monthly settlements, or similar. This will then require the backend system to be able to generate its own SAF-T report, which should be reported alongside the PowerOffice SAF-T report upon request from The Norwegian Tax Administration. If this alternative is chosen, it's important that the SAF-T report from the backend system and the SAF-T report from the accounting system are cross referenced with an audit trail. This is done by setting the SaftSourceId and SaftBatchId fields at the transaction level when transferring vouchers and transactions to PowerOffice.

Practical example of alternative 2:

PowerOffice receive sale transactions from an integrated backend system. The backend system transfer the transactions daily as a summary post (batch voucher) where sales are grouped per account per day. In isolation, the SAF-T export from PowerOffice will not be sufficient to provide adequate customer and supplier specification in the reporting, to satisfy the NBL ?3-1 first paragraph numbers 3 and 4. The backend system are then required to prepare a SAF-T report to complement the PowerOffice SAF-T report.

For instance, if the backend system has generated 3 invoices, 3 vouchers with transactions will be registered in the backend systems SAF-T file. In the PowerOffice SAF-T file, this is summed up as one voucher for the day. To cross reference these, the following must be done:

The backend invoicing system has 3 transactions in its SAF-T export. Each of these three transactions must then be tagged with the following on each transaction

  • BatchID, which is the identifier of the "batch" they have chosen to put the invoices into; this must be transferred from the backend system to PowerOffice upon creating the voucher, to act as a crossreference in the PowerOffice SAF-T report.

  • GLPostingDate?must be set by the backend system with the date of record in PowerOffice, which should correspond to the time when the batch voucher was posted in the accounting system. Additionally, PowerOffice must also receive information from the backend system about which?SystemID?they use in their SAF-T file AuditFileHeader. This is done in order for PowerOffice to set an identifier in the SAF-T file that reference the system that created the transactions.

PowerOffice will have one voucher in the SAF-T export, with aggregated transactions. The transactions need to include the following properties:

  • SourceID, which is the SystemID the backend invoicing system has in its AuditFileHeader, which the invoicing system must have transferred to PowerOffice upon creating the voucher in PowerOffice.

  • BatchID, which is the identifier of which batch the backend invoicing system put the invoices into. PowerOffice must get this transferred from the backend system upon voucher creation in PowerOffice.

  • GLPostingDate, which is filled out with the time of recording in PowerOffice (the PostingDate). Must match the corresponding date in the backend SAF-T


Using our api in alternative 2:

When posting vouchers via our api using the Voucher endpoints, the integration must specify two fields on the header of the voucher. These are SaftSourceId and SaftBatchId. These fields will be included at the transaction level (AuditFileGeneralLedgerEntriesJournalTransaction) in the PowerOffice SAF-T file and should correspond with SystemId in AuditFileHeader and BatchId on all transactions included in the summary post in the backend systems SAF-T export. Additionally, the backend system must keep track of the date for transfer to the accounting system (PostingDate on the transactions). This should then be mapped in the back end systems export on GlPostingDate on all related transactions.


Summary


The best alternative to ensure correct SAF-T reporting for the client is to transfers purchases/sales individually instead of summary posts (Alternative 1). This will create a significant number of additional vouchers in PowerOffice, but it will simplify SAF-T reporting since the backend won't need to prepare its own SAF-T report. For backend systems that cannot provide SAF-T reports, this option is the only viable option in terms of the NBL requirements.