Transferring payment events

Workflows > Usecase > eCommerce, POS and payments > Payment events

Use case: This use case involves integrating payment events into PowerOffice by separately posting accounting events for payments and invoices, using BankJournal vouchers and custom matching references for precise reconciliation and account management.

Important supplementary information:

Sales are often documented and posted as invoices, but all sales might not be credit sales. The end customer might already have paid using creditcard, Vipps etc - or your webshop use a third party like Klarna.

Payments are accounting events that are separated from invoices and the invoice process in PowerOffice, and the payment method in itself is of no concern, as described in this article. Payment events will need to be posted to PowerOffice by the integration, typically using a BankJournal voucher and <customMatchingReference> as the preferred tool for matching purposes.

Clients will commonly want to have dedicated asset accounts for their various payment methods, for instance (account codes only for the sake of the example):

  • Account 1901: Visa

  • Account 1902: Mastercard

  • Account 1903: Vipps

  • Account 1904: Klarna

Example: Webshop sale of NOK 12 500, paid by end B2C customer using Vipps

  • Sale and invoice is posted debit customer ledger NOK 12 500, <customMatchingReference == invoice number or other unique identifier> / credit sales account with relevant vat code, NOK 12 500

  • Payment event is posted debit 1903 Vipps NOK 12 500 / Credit customer ledger, <customMatchingReference == same as above> NOK 12 500

  • The customer invoice is matched with the payment and is no longer an open item in the customer ledger, the balance is transferred to the intermediate Vipps account.

  • When Vipps payout to the client: Typically posted as debet 1920 bank account / credit 1903 Vipps.

It is most common and generally recommended to transfer and post all daily payment events in one daily BankJournal voucher to PowerOffice, reflecting all payments in one daily update. Example:

  • Debit <sum payment> Vipps

  • Credit customer ledger customer 1, <customMatchingReference == unique invoice 1>

  • Credit customer ledger customer 3, <customMatchingReference == unique invoice 2>

  • ......

  • Credit customer ledger customer N, <customMatchingReference == unique invoice N>

Transferring payment events to PowerOffice - FAQ:

Q: How do i mark an outgoing invoice as paid?

A: As described above, an invoice and payment(s) of that invoice is considered different accounting events. The payment transactions must be transferred and posted to PowerOffice, and matched with the invoice.

Q: I need to send an invoice using PowerOffice, but the sales order is already paid in the eCommerce solution

A: We reiterate that the payment is a separate event that need to be posted to PowerOffice. With the use of <customMatchingReference> as the primary matching reference, the ordering of the accounting event does not matter. The payment can be transferred and posted to PowerOffice before the invoice is generated and posted (and vice versa). Do note that if an invoice already paid is issued from PowerOffice, the invoice information (typically the pdf the end customer receive) should reflect this - so that the end customer does not pay again or get confused about the payment state. The invoice text and information is set up by the client in the settings for what is called "branding themes" in PowerOffice. Which branding theme to use on sales orders transferred to Go is set by the property <brandingThemeId> or <brandingThemeCode>.