These accounts contain any expense of the organization, and all begin with

`Expenses:`.

### Income Accounts

These accounts contain any income of the organization, and all begin with

`Income:`.

### Unearned Income Accounts

`Unearned Income:` accounts are used to refer to revenue that is currently

received for services which have not yet been delivered.  The most typical

and common place an NPO encounters this type of income is for conference

registrations.  Since conference registrations arrive in advance of the

conference, it is not proper under accrual accounting to call it income until

such time as the conference successfully completes.

### Reporting The Chart of Accounts

The

[`general-ledger-report.plx` script in the `non-profit-audit-reports` Ledger CLI contrib directory](https://github.com/ledger/ledger/blob/next/contrib/non-profit-audit-reports/general-ledger-report.plx)

will generate a file called `chart-of-accounts.csv`, which is the chart of accounts.

The main command-line program though, that generates the chart of accounts

looks like this:

    $ ledger -f accounts/main/books.ledger -V -F "%-150A\n" -w -s -b 2012/01/01 -e 2013/01/01 reg

Note that this is bound by date.  Typically, it makes sense to list your

chart of accounts for a specific period (e.g., your fiscal year), since your

accounts might have some cruft in them from previous years that should now be

ignored.  (For example, if your organization simplified its chart of accounts

in later years, you don't want to report those old accounts that are no

longer used.)

Handling Fiscal Sponsorship

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

NPOs that do not provide fiscal sponsorship services will find this section

somewhat useless.  One of the biggest benefits of Ledger CLI is its

incredible flexibility that just does not exist in other accounting systems.

This section describes how to exploit that flexibility to provide a

separation in your books and reporting to handle earmarked accounts for

fiscally sponsored projects.

NPOs that don't need this feature can, in most cases, use the methods

described herein to deploy Ledger CLI, but should leave out the `:General:`

and `:ProjectNAME:` parts of the account hierarchy, since these are the

primary mechanisms used herein to handle the fiscal sponsorship structure.

### Earmarked Accounts

Many fiscal sponsor NPOs keep earmarked accounts for their member/affiliated

projects.  Furthermore, these projects often may either (a) terminate their

agreement with the NPO, and thus deserve a copy of their books that they can

"take away" with them, or (b) might be affiliated with *other* NPOs that also

hold accounts.  This system of earmarked accounts is designed to make it easy

for projects to have a copy of their own accounts, but not interfere with nor

even be aware of (a) the books of other member/affiliated projects, and (b)

the overall books of the entire NPO.

On the latter point, this system utilizes a directory structure and separate

`.ledger` files to separate out the different projects into different

structures.  This allows member/affiliated projects to take their data and

run `ledger` commands against it, separately and without access to the other

`.ledger` files of the NPO.

Proper Documentation For All Transactions

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

Ledger CLI offers a flexible structure of tagging any entry, including

separate tags for parts of a split transaction.  This system uses those tags

to ensure proper documentation is included for each financial transaction

that occurs for the organization.

Note that since Ledger CLI is a complete double-entry accounting system, each

transaction can correspond to multiple entries in the general ledger.  The

data entry format of Ledger CLI lists each double-entry accounting

transaction in a text file.

Documentation may in fact differ for entries within the transaction.  Ledger

CLI's tagging structure is flexible in this regard: each portion of a

double-entry transaction can carry the same tag or a different tag.  For

example, in this entry:

    2012-05-03 Sir Moneybags

            ;Entity: Sir-Moneybags

            ;Invoice: accounts/documentation/org/invoices/2012-05-30_moneybags-invoice_as-sent.txt

        Accrued:Accounts Receivable:Conservancy  $100,000.00

        Income:Main Org:Donations               $-100,000.00

            ;IncomeType: Donations

The portion of the transaction that credits the `Income:Main Org:Donations`

has three tags: [`Entity`](#entity-tag), [`Invoice`](#invoice-tag) and

listed at the top of the transaction, propagate through and apply to both

sides.  But, the `IncomeType` tag, which has no meaning for `Accrued:`

accounts, is applied only to the `Income:Main Org:Donations` part of

the transaction.

Below you'll find detailed descriptions of all the possible tags that are

used in this system.  The actual declarations and enforcement of rules of

these tags can be found in the file `accounts/config/config-tags.ledger` in

this project.

### Documentation Tags

Documentation tags are tags that link to other backup documents that provide

evidence and details that justify a particular ledger entry.  The value of

the tag is a relative path name of a file elsewhere in the same repository

that documents the specific expense.  For example, an entry like this:

     2012-02-05 Office Supply Galore - Online Order

         Expenses:Main Org:Office Supplies     $35.00

             ;Receipt: accounts/documentation/org/receipts/2012-02-05_office-supply-galore.txt

         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/pub/irs-pdf/fw9.pdf) for the individual

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

link to a

[W8-BEN](https://www.irs.gov/uac/form-w-8ben-certificate-of-foreign-status-of-beneficial-owner-for-united-states-tax-withholding)

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.

The most important USA-related issue tracked by this tag are contractors who

go along with a TaxImplication tag.

The possible values for this field are:

* `1099`, indicating the amount paid requires issuance of a USA Federal Form

  1099 for the `Entity` involved.

* `W2`, indicating the amount paid will be part of a USA Federal income, as

  reported on Form W2 report for the `Entity` involved.

* `Retirement-Pretax`, indicating the amount paid was made to a W2 employee

  as part of pre-tax retirement plan, such as a 401(k) or 403(b) plan.

* `Accountant-Advises-No-1099`, indicating that the circumstances and rules

  seem to indicate a USA Federal Form 1099 should be issued for the `Entity`

  involved, but an outside accountant advised that no 1099 needs be issued

  for this `Entity`.

* `Bank-Transfer`, indicating that the amount is a transfer between two

  banking accounts under the control of the NPO itself.

* `Foreign-Individual-Contractor`, indicating that the NPO has established

  that the `Entity` is a contractor residing outside the USA who is not a USA

  citizen and does not for any reason pay taxes in the USA.

* `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

Form 990, [Schedule I](https://www.irs.gov/uac/about-schedule-i-form-990) and

[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: