Get all transactions customer ledger transactions

1. Retreive the customer ledger statement between two dates (dates inclusive)

2. Use the desired filtering and fields to report what you need

Checking for new invoices and general payment information of invoices

1. Retreive the customer ledger statement, use av quite broad date range

2. Include filter on the voucher types outgoing invoice and outgoing creditnote

3. Include filter on last changed

4. Use other desired filtering and fields to report what you need.

This query can be used to check for new invoices, and existing invoices with changes. The only element that can change on a posted invoice/credit note is the match state, thus providing information of the change in balance of the invoices. Note that this particular workflow can be substituted/covered with the outgoing invoice endpoint (LINK), relevant for general outgoing invoice reporting purporses.

Checking for detailed payment transaction information

1. Retreive the customer ledger statement, using av quite broad date range

2. Include filter on returning entries with balances less than amount

3. Include last changed filter

4. Use other desired filtering and fields to report what you need.

This query can be used to check for new match states, thus providing detailed information of the payment entries (and other match events). Take note that the filter set to return entries with balances less than amount, will not provide information of any unmatching events, if a user in Go unmatches two linked entries. Although manual unmatching might be considered edgecases, this information can be retreived by leaving out the balances less than amount filter in step 2. Using only a last changed filter, both new and changed entries will be returned.

For the last two workflows mentioned above, it is recommended to use a broad daterange when getting the customer ledger statement. The reason for this, is that the dates define the posting date interval (accounting wise), not to be confused with the time of matching which may happen at a later date, if matched manually. This can be illustrated with an example: An invoice might have a posting date months before the accounting transaction date of the payment, and the matching of the two might be handled manually by the accountant a month after the payment date. In order to properly catch such a situation, the date range must be set broad.

*A general note and explanation of the match state

Invoices and payments are considered two different accounting events in PowerOffice Go. The payment status of invoices, are directly linked to the state of the invoices in the customer ledger in Go. An invoice is considered paid/partially paid, if it is matched with transactions of the opposite amount, from one or more separate vouchers.

Matching in the customer ledger occur when two or more transactions share the same reference when posted, or if they are manually matched in the user interface. When matched, the related transactions in the customer ledger will share the same value of a match identifier, and the balance of the entries will reflect the remaining amount to be paid (zero if the amount is fully matched).

Using a simplified example of a vat free invoice and a payment as an example:

Consider an invoice sent to customer number 10018, with the amount 1250. The invoice voucher is typically posted as follows in Go:

• Debit customer ledger account 10018, amount 1250

• Credit general ledger sales account, amount 1250

The invoice is an open item in the customer 10018's ledger (unpaid state).

Let's assume the invoice is fully paid, and a payment voucher posted in Go:

• Debit bankaccount, amount 1250

• Credit customer ledger 10018, amount 1250

In the customer 10018' ledger, the debit invoice entry and the credit payment entry are matched, and the invoice will be considered paid (no longer an open item, balance == 0). The two entries will be linked with the same match identifier.

Prerequisites

• Access to the CustomerLedger access privelige

  • The client need an active subscription of an accounting module of PowerOffice Go

Related workflows:

• Account Transactions

• Outgoing Invoices

• Supplier Ledger

• Dimension endpoints to supplement information

• Contact endpoints to supplement information
  

Dictionary/Terminology:

• General ledger account: In accounting terms, this is an ordinary account used in the general ledger of the accounting system

• Account transaction: A singular transaction posted on a given general ledger account. A posted voucher allways consist of at least two account transactions, one debit (positive) and one credit (negative) - allways balancing to zero.

• Subledger: A subset of a general ledger account, containing spesifications of the transactions for either customers, suppliers or employees. In PowerOffice Go, a general ledger acccount that have a subledger, require the use of the subledger account number (ie the customer/supplier/employee number) when transactions are posted.

• Subledger transaction: A singular transaction posted in a subledger.

• Open item: A subledger transactions that have a balance not queal to zero (ie an amount remains to be paid)

• MatchId: The identifier used by the system to represent that transactions are connected and related, thus reducing the balance (remaing amount to be paid)