Liabilities:Credit Card:Visa         -$35.00

shows that a purchase was made at Office Supply Galore's online store for

$35.00, and the file

`accounts/documentation/org/receipts/2012-02-05_office-supply-galore.txt`

contains the receipt from that purchase.

#### Receipt Tag

The `Receipt` tag refers to receipt of some sort.  Typically, this is a

document that shows clear confirmation that the transaction has already

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

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

Some examples of appropriate uses of the `Receipt` are:

* a point-of-sale credit card receipt from a purchase, given by a cashier or

  sent via email after the purchase has occurred.

* a deposit slip given at the bank upon making an over-the-counter deposit of

  paper checks.

* a confirmation document showing an outgoing wire transfer made by a bank.

* a confirmation document showing transfer of funds between two bank

  accounts.

* A pay advice document generated upon payment of an invoice.

#### Invoice Tag

The `Invoice` tag refers to an actual invoice, either generated by the

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

links to a [W-9](https://www.irs.gov/forms-pubs/about-form-w-9) for the individual

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

link to a

[W-8BEN](https://www.irs.gov/forms-pubs/about-form-w-8-ben)

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

  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

        Liabilities:Credit Card:Visa            $-100.00

        Expenses:Conservancy:Hosting             $100.00

    2012/01/01 My Bad Billing Hosting - REVERSAL - NEVER CHARGED

        Liabilities:Credit Card:Visa             $100.00

        Expenses:Conservancy:Hosting            $-100.00

However, going forward, you'd likely never enter anything into the ledger

**until** you had real proof via an Invoice, Receipt or Statement that showed

the Expense did/should occur.  This use of `NEVER CHARGED` in the payee is

thus deprecated.

#### Income Account Documentation

Each `Income:` account must have the following tags:

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

  [`Statement`](#statement-tag), or

  [`Contract`](#contract-tag).  Exceptions to this requirement are as follows:

     + the income generated from the transaction is less than $800, or

     + the `IncomeType` is `RBI` and the income is for a defined, public

       program (such as conference registration)

* An [`Entity`](#entity-tag) tag, *iff.* the Income for the transaction is

  for more than $800.

* An [`IncomeType`](#incometype-tag) tag.

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

Reports For Various Situations

------------------------------

When data is well formed as specified herein, there are various quick reports

that can be used to verify certain conditions or issues with accounting.

Here are a few examples:

### Verifying That An Invoice Is Paid

Assume for this example that the shell variables `entity`, `program`, and

`invoice` are set as follows:

    $ entity=Sir-Moneybags; program='Main.*Org:.*Direct'; invoice=2012-05-30

If the invoice was paid, this ledger command will have two lines of output,

and the second line will be a transaction on the payment date.  If only one

line appears, it's the receivable accrual and we see the invoice is not paid.

    $ ledger -f accounts/books.ledger  -V --sort d --limit 'tag("Entity") =~ /'$entity'/ and tag("Program") =~ /'$program'/ and tag("Invoice") =~ /'$invoice'/' reg /Accrued/

Alternatively, the following command will only have output if the invoice is unpaid:

    $ ledger -f accounts/books.ledger  -V --limit 'tag("Entity") =~ /'$entity'/ and tag("Program") =~ /'$program'/ and tag("Invoice") =~ /'$invoice'/' bal /Accrued/

### Calculating Donation Portion of Invoice

As described in

[IRS 501(c)(3) rules](https://www.irs.gov/charities-non-profits/substantiating-charitable-contributions),

a charity must substantiate portions of a contribution that are RBI, and

portions that are donations separately and inform the donor which portion was

a donation that may be eligible for tax deduction.  Use of the `IncomeType`

tag facilities collection of the necessary data to determine the total, and

the following command line will total up all the donation portions for a

particular invoice: