Payments

Workflows > Endpoints > Sales Orders > Payments

Purpose: Transferring sales order/invoice payments to PowerOffice.

The end customer might already have paid the sales order using creditcard, Vipps etc - or your webshop use a third party like Klarna. This article describe how to hande payments in the process of transferring sales orders and invoicing them from PowerOffice.

Typical usecases: ECommerce and webshops that use PowerOffice to generate and send invoice to the end customer. This can also be the case for POS systems or any external order system using the same workflow.

Important distinctions: 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 use case article. Payment events will need to be posted to PowerOffice by the integration, typically using a bank journal 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

Endpoint

Description of the core workflow

  1. Webshop sale of NOK 12 500, paid by end B2C customer using Vipps

  2. Sales order is transfered to PowerOffice and invoiced to both post the sale in PowerOffice and deliver the invoice document to the end customer. 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

  3. Payment event is posted by the integration with a bank journal voucher, debit 1903 Vipps NOK 12 500 / Credit customer ledger, <customMatchingReference == same as above> NOK 12 500

  4. 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.

  5. Settlement from Vipps to the client: Typically posted as debet 1920 bank account / credit 1903 Vipps, by an integration.

Best practice approach for transferring payments:

  • 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>

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>.

Prerequisites

Required steps when transferring payments

  • Access to the BankVoucherPosting endpoint

  • Control the matching mechanism by using either <customMathcingReference> or <invoiceNo>. The first property allow for payments to be posted before the invoice is created. With <invoiceNo>, this can only be used on bank journal vouchers after the sales order is invoiced and an invoice number is assigned.

Related use cases

Dictionary/Terminology:

  • An sales order and an invoice draft are the same concept in Go (same base entity, same functionality, except sent/posted state).

  • An invoice in PowerOffice is posted invoice voucher, and there are two sources to posting a voucher: Transform a sales order to an invoice by issuing and sending invoice from PowerOffice, posting the voucher in the async send process. Alternatively, invoices that are already created and sent from external system can be posted/imported to PowerOffice.