Detailed Accounting Reporting

Workflows > Usecase > Reporting > Detailed Accounting Reporting

Use case: Retrieving detailed accounting information on account balances and the general ledger transactions, for reporting purposes

The purpose of this article is to provide an overall description and general recommendation on how to combine and retrieve trial balance and account transactions for detailed reporting purposes of the accounting (for example reporting tools, datawarehouse and business intelligence solutions)

Retrieving the trial balance as a starting point, and from then on all account transactions, will provide the integrated party with a lot of flexibility in terms of constructing accounting reports.

Recommended prerequisite

For reporting purposes, we generally recommend and assume that transactions are stored in a database, and that the integration query and retrieve only new data (after the initial retrieval of historical data).

Definitions

Account transactions and vouchers:


An account transaction is representing an accounting entry. This is a single posted amount on a general ledger account. An account transaction is part of a voucher, and a voucher allways consist of at least two account transactions (one debit and one credit), and it will allways balance (sum debit transactions and sum credit transactions equal zero).

The source of the various vouchers will vary. Some examples:

  • Outgoing invoices generated and sent from Go

  • Incoming supplier invoices received by EHF delivery to Go

  • System generated transactions (depreciation, vat, ocr, bank remittance files)

  • Imported vouchers created via the api or from an import file

  • Manual type vouchers created by users in the journal entry workflow

PowerOffice Go seperate vouchers in types, described in more detail here (the VoucherType schema). Regardless of the voucher type, all vouchers are assigned a voucher number by the system and in the same number sequence, starting on voucher number 1 when a client start using Go and the first voucher is posted.

Another feature of Go is that the accounting information of a posted voucher cannot be altered. Only the description field can be changed on vouchers already posted in Go. Any other change that involve a change of the accounting information, will automatically generate a reversal voucher (reversing the original) and a new voucher with the corrections made.

Conversion date and trial balance:


The trial balance is a list of the general ledger accounts from the client and the current aggregated balance of these accounts at a given date. The trial balance, used for reporting purposes on a more aggregated level, must be used as the starting point for an integration retrieving account transactions.

The commom case when our customers start with Go, is that they came from a different accounting system and convert to Go (unlsess it is a brand new startup company). In Go, a conversion date is set on the client: That is, at which date will our customer start using Go (with vouchers starting on the number 1). And, by definition, this defines the date of the opening balance - the day before the conversion date. The opening balances of the client will be imported on the conversion date -1 day.

The opening balances and starting point for an integration, will be to retrieve the trial balance for the day before the conversion date.

General approach for retrieving all transactions from Go

  1. Get the conversion date from the accounting settings endpoint

  2. Get the trial balance from the day before the conversion date, and store the information

  3. Retreive the account transactions between the conversion date and the date the integration start syncing, but retrieve in intervals with date filtering (max 6 months at a time).

  4. Start polling the account transactions endpoing with a wide date range, but use a logic with filtering on voucher number greater than the highest voucher number last retrived and registered in your end