organization or received by the organization.  Typically, this is a document

that is a request for payment, rather than documenting an actual payment that

has occurred.  The value of the `Invoice` tag is always a valid pathname in

repository to the document, [as described above](#documentation-tags).

Some examples of appropriate uses of the `Invoice` tag are:

* an actual invoice as sent by a vendor to the organization.

* a request for payment sent by the organization to someone else.

* a reimbursement request submitted by an employee, contractor, or volunteer

  for expenses they've already incurred and would like the organization to

  reimburse (e.g., an expense report, requesting for reimbursement of travel

  expenses).

#### Statement Tag

The `Statement` tag refers to any sort of written statement received from an

external party (or even perhaps generated internally) that provides document,

insight, or other information about the transaction.  The value of the

`Statement` tag is always a valid pathname in the repository to the

document, [as described above](#documentation-tags).

Some examples of appropriate uses of the `Statement` tag are:

* bank statements, as received from the banking institution.

* written reports of travel.

* blog posts made by a contractor documenting their work.

* written organizational policies about the expense.

* just about anything that is clearly not an [invoice](#invoice-tag) nor a

  [receipt](#receipt-tag), but definitely is valid backup documentation for

  the transaction.

#### TaxReporting Tag

The `TaxReporting` tag is an optional tag for `Assets` accounts that debit to

the account.

When provided, the `TaxReporting` tag accompanies a `TaxImplication` information

tag.  The TaxReporting refers to a document that verifies the choice for the

`TaxImplication` tag.  For example, for individual contractors in the USA, a

`TaxImplication` of `1099` would be well served by a `TaxReporting` that

being paid.  For a individual foreign contractor, the `TaxReporting` might

link to a

for the payee.

### Information Tags

In contrast to documentation tags, information tags can more traditionally be

considered pure "meta-data" for a ledger entry.

#### Entity Tag

The `Entity` tag is required for many types of ledger entries.  The value of

the `Entity` tag is a unique moniker that identifies the organization,

company, person, or legal entity that is the external party for the

transaction.

Note that there is no database of these monikers, so typos can cause

trouble.  However, you could implement checks in

`accounts/config/config-tags.ledger` using a regular expression to verify no

typos have occurred.  This would be somewhat cumbersome, since Ledger CLI

would likely require that the monikers be encoded into a regular expression.

Barring that, the

[integrity of your data should be periodically checked](#checking-integrity-of-a-tag).

#### IncomeType Tag

The `IncomeType` tag is used for all `Income` accounts.  This refers to the

type of income.  The value of the `IncomeType` tag is always a string.

Since this particular system is designed for USA non-profit entities who file

USA Form 990, the following `IncomeType` values are supported:

* `Donations`, which refers to standard charitable donations.

* `RBI`, which refers to "related business income".

* `UBTI`, which refers to "unrelated business taxable income".

Not that donor-advised funds and government grants don't currently have their

own `IncomeType`.  It's possible this might be necessary; the authors aren't

familiar with how to handle those items on the Form 990.  It would be a

relatively simple change to `config-tags.ledger`, though, to support other

income types, or to change it entirely to handle use-cases other than USA

Form 990 filing.

#### TaxImplication Tag

The `TaxImplication` tag is used for all `Asset:` accounts when the

transaction includes a payment of $10.00 or more leaving the account.  This

tag catalogs any tax implications that might occur on outgoing funds.

* `Foreign-Corporation`, indicating that the NPO has established

  that the `Entity` is a corporation outside the USA.

* `USA-Corporation`, indicating that the NPO has established that the

  `Entity` is an incorporated entity the USA (i.e., "Inc."), and therefore no

  1099 is required.

* `USA-501c3`, indicating that the NPO has established that the `Entity`

  has federal 501(c)(3) status in the USA, and therefore no 1099 is required.

* `Refund`, indicating that the amount is a refund owed to the `Entity` from

  an amount previously paid to the NPO.

* `Reimbursement`, indicating that the amount is a reimbursement of expenses

  incurred by the `Entity` and thus it is not income to the `Entity`.

* `Tax-Payment`, indicating this is a tax payment to a taxing authority (such

  as the state or federal government) (e.g., a unrelated business income tax

  payment).

* `USA-LLC-No-1099`, indicating that the `Entity` is an LLC, but not the type

  of LLC for which the USA requires issuing a 1099.

* `Loan`, indicating that the `Entity` is receiving these funds as a loan

  that is expected to be paid back.

#### Program Tag

The `Program` tag is used primarily to track program activity for `Income:`

and `Expenses:` accounts.  This allows for knowing what particular initiative

initiated the income (e.g., a specific fundraising campaign) and/or what

particular program activity an expense is toward (e.g., funding travel to

some specific conference).

The Program tag is always a string with the same format as a Ledger CLI

account (primarily for use with Ledger CLI's `--pivot` and `--group-by`,

[as described later](#testing-program-success)).

#### GrantLocation Tag

The `GrantLocation` tag is used to indicate that an expense is a grant.  The

value for the tag should indicate the geographical region.  It is recommend

that the geographical reason be identified with the

[ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) two letter country

code for the country where the grant goes.

This tag is to assist in filing

[Schedule F](https://www.irs.gov/charities-non-profits/exempt-organizations-annual-reporting-requirements-foreign-activities-form-990-schedule-f-activities-reported).

### Account Type Documentation Requirements

Each account type has different documentation requirements.  Based on the

type of the account, it requires a different set of tags.

When Ledger CLI's `--pedantic` option is used, these rules are enforced by

ledger itself via the configurations found in `config-tags.ledger` and

`config-accounts.ledger`.

#### Expense Account Documentation

Each `Expenses:` account entry must be tagged with the following tags:

* One of: [`Invoice`](#invoice-tag), [`Receipt`](#receipt-tag), or

  [`Statement`](#statement-tag).  (The only exception to this rule: an entry

  does not need an `Invoice`, `Receipt`, nor a `Statement` tag if the

  [payee was never charged](#never-charged-payee).)

* A [`Program`](#program-tag) tag.

Expense accounts can have the following optional tag:

* A [`GrantLocation`](#grantlocation-tag) tag.

#### NEVER CHARGED Payee

The only exception to the standard tagging requirement is when the payee has

been modified to indicate that the expense was `NEVER CHARGED`.  This is a

historical special-case.  The solution was originally designed for the

following scenario:

Suppose an expense was expected — for example, a situation where you

gave a credit card number to charge something and the charge never came

through — but it turns out the charge never happened.

The recommended way to resolve this problem in the system is to just delete

the entry entirely from the Ledger file, and allow the VCS to log the fact

that the charge was expected, but the vendor never billed the credit card.

The reason the `NEVER CHARGED` payee text was added was to handle the

situation where the books included this charge, but the books were already

closed for the financial period (e.g., the books had already been audited).

Changing the payee was a method for documenting the expense.  You might use

it like this:

    2011/05/28 My Bad Billing Hosting - NEVER CHARGED