Accounting Auditing

Tackler has multiple features to support accounting auditing, assurance actions and financial audit.

Some examples of these are:

  • Native support for immutable, tamperproof accounting data

  • Proof of journal state at certain point in time

  • Proof of used journal data (transaction set)

  • Validation of all used accounts

  • Validation of all used commodities

  • Validation of all used transaction tags

  • Proof of used reporting parameters

  • Open Source code base and test setup

Tackler is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Tackler’s features for Auditing and Assurance actions

Support for Immutable, Tamperproof Accounting Data

Tackler’s Git storage backend provides immutable, cryptographic strong evidence of journal’s data. This information is included in reports' metadata. It is possible to rerun reports based on old, original journal data, and be assured that same journal data was used for new reports than what was used originally in the past.

See Git Storage documentation, and High-Low Security Accounting example for further details.

Proof of Journal State

The state of journal is included into each report when git storage is used. This is cryptographically strong, immutable description of the state of journal at certain point of time. This makes it possible to process the exactly same journal data in the future.

Example of journal metadata section
Git Storage
      reference : main
      directory : txns
      extension : txn
         commit : e366a07a09d39a306d6beb1e86de5729ac9acc1d
         author : ACME HQ <hq@acme>
           date : 2024-12-17 16:00:00 +0000
        subject : hq: merge store B

Proof of Used Journal Data

Tackler can provided proof of used journal data with reports. This proof is cryptographically strong checksum of transaction set used with reports.

This transaction set checksum can be used as an evidence and assurance that all intended transactions are included into calculations, and it’s possible to easily re-calculate this checksum without Tackler by external system.

Combined information provided by Git storage backend and Txn Set Checksum creates immutable and persistent evidence of used accounting data in calculations.

Transaction Set Checksums are reported when audit mode is activated.

Example of Transaction Set Checksum metadata section
Txn Set Checksum
        SHA-256 : 940cb81d9f3b728a51d21251b891f62798c081d25e70a838aeb53c8199d33d3e
       set size : 5

Tackler’s contrib directory has an example script txn-set-checksum.sh to demonstrate how to externally calculate Txn Set Checksum.

Correctness of Accounting Data

Tackler has a strict mode, which validates account names, commodity names and tags. This is useful for ensuring that all transaction data is correctly entered and that the reports are accurate. To enable strict mode, set kernel .strict = true in tackler.toml configuration file.

You can enable strict mode with the template journal.

Use tackler new command to create a functional template journal:

tackler new journal
tackler --config journal/conf/tackler.toml

Validation of Accounts

If accounting system allows usage of undefined accounts and doesn’t enforce account name validation, it is possible to lose or leak value into unknown, not tracked accounts, even when transactions still balance internally perfectly.

By enabling strict account validation, the Chart of Accounts is well-defined, and accounting data can’t be lost due typos.

See accounts.toml for further info.

Validation of Commodities

In addition to strict mode for accounts, tackler supports strict mode for commodities. When strict mode is activated, then also commodities are checked with defined Chart of Commodities.

When strict mode is activated, it is possible to set configuration option that allows empty commodities (e.g. value posts without unit or commodity), or this can be disallowed, if all transactions must have a commodity.

See commodities.toml for further info.

Validation of Tags

When strict mode is activated, then also transaction tags are checked with defined Chart of Tags.

See tags.toml for further info.

Proof of Reporting Parameters

Account Selector Checksums

Account Selector Checksum is cryptographic proof of used rules which are used to select which accounts will be used for reports. Account Selector Checksum makes it easy to compare two potentially complex Account Selectors and see immediately if they are same.

Account Selector Checksums are reported when audit mode is activated.

Example of Account Selector metadata section
Account Selector Checksum
        SHA-256 : 7d18093d24860c5ccf354bd72b67cbb29ff753d83384367cb86cceade07f1d6b
      selectors : 'Assets(:.*)?'
                | 'Warehouse(:.*)?'

Transaction Filters

Description of transaction filters is included into reports when a filter was used to select only part of transactions to be used for reporting.

Example of Transaction Filter metadata section
Filter
  Txn Tags: "store-a"

Open Source Code Base and Test Setup

Tackler and it’s test setup are open source, so it’s possible to do external audit of code base, tests or both.

Tackler’s code base is tested extensively. Testing includes unit and logical testing to validate tacklers features. The logical test coverage of features is tracked by Tackler Test Tracking Database (T3DB).

Tackler is also tested with very large transaction sets (up to one million transactions) to detect any anomalies with larger data sets.

For further info, see Reliability and Performance documentation.

Examples of reports with audit metadata

Below are links to reports with audit metadata. These reports are part of the tackler’s test system.