Retrieving Invoice Payments

Workflows > Usecase > Reporting > Retrieving Invoice Payments

Use case: Payments of either outgoing invoices and/or incoming invoice need to be retrieved to the external system integrated.

This can be the case for any integrated solution with a workflow related to sales orders, outgoing invoices or incoming invoices, where the payment state of the invoices are relevant information for the external system.

Some examples of systems and cases where the payment state of invoices might be relevant:

  • CRM and invoicing systems

  • Backend order or purchase order systems

  • POS systems invoice/order support

  • eCommerce/webshops

  • General reporting purposes/reconciliation

The purpose of this article is to provide a general description of how payments and invoices are connected in PowerOffice, and how to approach retrieving the payments base on the details needed.

Note that we also have an article describing related but more specific use cases relevant for creating invoice payments:

  • ECommerce, POS and payments use case

Simplified examples

Outgoing invoice to customer:


Consider an invoice with invoice number 12345, sent to customer with number 10018, with amount 1250 (no vat for the purpose of the example). The invoice voucher transactions is posted as follows in PowerOffice:

  • Debit customer ledger 10018, amount 1250, invoiceNo = 12345

  • Credit sales account 3000, amount 1250

The invoice is an open item in the customer ledger of the customer number 10018 (unpaid state) until it is matched with a transaction of opposite amount.

Let's assume the invoice is fully paid by the customer, and the payment are posted in PowerOffice with a bankjournal voucher type:

Debit bank account 1920 (or any defined "dummy"-account for the payment type*)

Credit customer ledger 10018, amount 1250, invoiceNo = 12345

The use of the same <invoiceNo> property will ensure that the two customer ledger transactions for the customer 10018 will be matched with the same <matchId>, and the invoice will be considered paid (no longer an open item, <balance = 0>).

*Payment types is not a concept in PowerOffice that is used directly, and have no implication in itself. Usually the accountant/client want to have specific accounts or dedicated ledger accounts to represent the payment method (ie a dedicated account for Visa/Mastercard/Paypal etc), in order for easier reconciliation.

Incoming invoice from supplier:

Consider an invoice with invoice number 56789, received from the supplier with number 20034, with amount 1250 (no vat for the purpose of the example). The invoice voucher transactions is posted as follows in PowerOffice:

  • Debit cost account 4000, amount 1250

  • Credit supplier ledger 20034, amount 1250, invoiceNo = 56789

The invoice is an open item in the supplierledger of the supplier number 20034 (unpaid state) until it is matched with a transaction of opposite amount.

Let's assume the invoice is fully paid by client (payout to the supplier), and the payment are posted in PowerOffice with a bankjournal voucher type:

  • Debit supplier ledger 20034, amount 1250, invoiceNo = 56789

  • Credit bank account 1920, amount 1250

The use of the same <invoiceNo> property will ensure that the two supplier ledger transactions for the supplier 20034 will be matched with the same <matchId>, and the invoice will be considered paid (no longer an open item, <balance = 0>).

Retrieving payments of invoices

How to best approach retrieving payments of invoices depend on the use case for the integration, and more specifically the level of details needed of payment information.


Simple reporting:

If the payment transaction information in itself is irrelevant, and only the balance of the invoices are relevant, consider using the invoice reporting endpoints to retrieve the payment state:

  • IncomingInvoices

  • OutgoingInvoices

For both endpoints: Use filter on <balanceLastChangedDateTimeOffsetGreaterThan>, set to the timestamp of your integration's previous (last) query. The result will be that only new invoices, or invoices with changes in the balance property in the subledger will be returned each query. Use this information to identify any payments or partial payments for returned invoices with <Balance> != <Amount>. Note that the query will also return changes related to any unmatching in PowerOffice. Credit notes are also returned in both endpoints mentioned above.

Alternative approach for simple reporting:

  • Using the "/Statement" endpoints in CustomerLedger or SupplierLedger :

  • Set a quite broad daterange in <fromDate> and <toDate>

  • Filter on lastChangedDateTimeOffsetGreaterThan, set to the timestamp of your previous query

  • Filter on voucherTypes corresponding with the relevant invoice types for the endpoint

  • Filter on onlyBalancesLessThanAmount (CustomerLedger) or onlyBalancesGreaterThanAmount (SupplierLedger)

This will return only invoice transactions with new changes in balance (and where balance !=Amount), allowing you to keep track of new full or partial payments, or invoices matched with credit notes.


More detailed reporting:

If information regarding the payment transactions is needed, use the "/Statement" endpoints in CustomerLedger or SupplierLedger :

  • Set a quite broad daterange in <fromDate> and <toDate>

  • Filter on lastChangedDateTimeOffsetGreaterThan, set to the timestamp of your previous query

This will return all new transactions in the subledgers, including information of payments. All transactions with the same <matchId> belong in the same match. This approach should be used if it is relevant to report the payment transactions as well (as opposed to only the balance state of the invoice).

Payment transactions will typically have the voucher types:

  • IncomingBankRemittance: Voucher type used in PowerOffice when outgoing payments are completed and information (payout) are returned from the integrated banks in our system. Primarily relevant in terms of payment of incoming invoices from suppliers.

  • IncomingOcrGiro: Voucher type used when incoming OCR (cid number payments) are posted in the system based on information from our integration with Mastercard Payment Systems (privously NETS). Primarily relevant in terms of customer payments of outgoing invoices.

  • BankJournal: Voucher type that can be selected and used when users create vouchers manually in PowerOffice or by using the api. Bank vouchers are the only voucher type that support the <invoiceNo> reference (in the GUI as well) for subledger transactions.

The above voucher types are the only ones can be considered payments by the nature of the voucher type. If transactions have any other voucher types, it is difficult to assess what the nature of the transaction is (in terms of program logic) - maybe the accountant wrote off an invoice or manually made some adjustments unrelated to a payment event.


Dictionary/Terminology:

  • <Balance>: Property of the customer or supplier ledger transaction. Technically, this property reflect the unmatched amount of the transaction. The practical interpretation is that of invoices: The balance of an invoice subledger transaction reflect the remaining unpaid amount (in relation to the original posted <Amount> property of the invoice.

  • <MatchId>: Property that identify a match between two or several transactions in a subledger with opposite amounts.