check

Check for various kinds of errors in your data.

Flags:
no command-specific flags

hledger provides a number of built-in correctness checks to help
validate your data and prevent errors. Some are run automatically, some
when you enable --strict mode; or you can run any of them on demand by
providing them as arguments to the check command. check produces no
output and a zero exit code if all is well. Eg:

hledger check                      # run basic checks
hledger check -s                   # run basic and strict checks
hledger check ordereddates payees  # run basic checks and two others

If you are an Emacs user, you can also configure flycheck-hledger to run
these checks, providing instant feedback as you edit the journal.

Here are the checks currently available. Generally, they are performed
in the order they are shown here (and only the first failure is
reported).

Basic checks

These important checks are performed by default, by almost all hledger
commands:

- parseable - data files are in a supported format, with no syntax
  errors and no invalid include directives. This ensures that all files
  exist and are readable.

- autobalanced - all transactions are balanced, after inferring missing
  amounts and conversion costs where possible, and then converting to
  cost. This ensures that each individual transaction is well formed.

- assertions - all balance assertions in the journal are passing.
  Balance assertions are like canaries in your journal, they catch many
  problems. They can get in the way sometimes; you can disable them
  temporarily with -I/--ignore-assertions (unless overridden with
  -s/--strict or hledger check assertions).

Strict checks

These additional checks are performed by any command when the
-s/--strict flag is used (strict mode). Strict mode always enables the
balance assertions check, also. These provide extra error-catching power
when you are serious about keeping your data clean and free of typos:

- balanced - like autobalanced, but in conversion transactions, costs
  must be written explicitly. This ensures some redundancy in the entry,
  which helps prevent typos.

- commodities - all commodity symbols used must be declared. This guards
  against mistyping or omitting commodity symbols.

- accounts - all account names used must be declared. This prevents the
  use of mis-spelled or outdated account names.

Other checks

These other checks are not wanted by everyone, but can be run using the
check command:

- ordereddates - within each file, transactions are ordered by date.
  This is a simple and effective error catcher, and you should use it.
  Alas! not everyone wants it. If you do, use
  hledger check -s ordereddates. When enabled, this check is performed
  early, before balance assertions (because copy-pasted dates are often
  the root cause of balance assertion failures).

- payees - all payees used by transactions must be declared. This will
  force you to always use known/declared payee names. For most people
  this is a bit too restrictive.

- tags - all tags used by transactions must be declared. This prevents
  mistyped tag names.

- recentassertions - all accounts with balance assertions must have a
  balance assertion within the last 7 days before their latest posting.
  This encourages you to add balance assertions fairly regularly for
  your active asset/liability accounts, which in turn should encourage
  you to check and reconcile with their real world balances fairly
  regularly. close --assert can be helpful. (The older balance
  assertions become redundant; you can remove them periodically, or
  leave them in place, perhaps commented, as documentation.)

- uniqueleafnames - no two accounts may have the same leaf name. The
  leaf name is the last colon-separated part of an account name, eg
  checking in assets:bank:checking. This encourages you to keep those
  unique, effectively giving each account a short name which is easier
  to remember and to type in reporting commands.

Custom checks

You can build your own custom checks with add-on command scripts. See
also Cookbook > Scripting. Here are some examples from hledger/bin/:

- hledger-check-tagfiles - all tag values containing / (a forward slash)
  exist as file paths

- hledger-check-fancyassertions - more complex balance assertions are
  passing
