Supplier Ledger

Workflows > Endpoints > Reporting > Supplier Ledger

Purpose: Retrieve supplier subledger specifications.

These endpoints are typically used in cases for detailed accounting reporting and detailed reporting of payment transactions. The supplier ledger provide a specification of the transaction entries posted in the supplier ledger. This includes general invoice information, payments and other transactions, and the match state* of transactions.

The recommended workflows for using these endpoints, is depended on the usecase and the need for information in the integrated application. Below are some examples of common variants, in the order of simplified usecases to advances usecases:

Endpoint

Description of typical usecase workflows


Getting a simple list of the current aggregated balance of suppliers:

  1. Retrieve the supplier balances at a given date (date incluse)

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

Getting open items

  1. Retreive the supplier ledger open items at a given date (date inclusive), providing a specification of the current balance of suppliers

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

Get all transactions supplier ledger transactions

  1. Retreive the supplier 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 supplier ledger statement, use av quite broad date range

  2. Include filter on the voucher types incoming invoice and incoming 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/creditnote 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 incoming invoice endpoint (LINK), relevant for general incoming invoice reporting purporses.

Checking for detailed payment transaction information

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

  2. Include filter on returning entries with balances greater 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 greater 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 greater 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 supplier 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 supplier 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 supplier 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 supplier 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 incoming invoice received from supplier 20018, with the amount 1250. The invoice voucher is typically posted as follows in Go:

  • Debit cost account, amount 1250

  • Credit supplier ledger 20018, amount 1250

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

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

  • Debit supplier ledger 20018, amount 1250

  • Credit bank account, amount 1250

In the supplier 20018' ledger, the first credit invoice entry and the second debit 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 SupplierLedger access privelige

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

Related workflows

  • Account Transactions

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