; -*- ledger -*-

; -*- coding: utf-8 -*-

!include ../config/config-npo.ledger

2012-02-05 Office Supply Galore - Online Order

    Expense:Main Org:Office Supplies          $35.00

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

    Liabilities:Credit Card:Visa             -$35.00

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

    Liabilities:Credit Card:Visa            $-100.00

    Expense:Main Org:Hosting                 $100.00

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

    Liabilities:Credit Card:Visa             $100.00

    Expense:Main Org:Hosting                $-100.00

### Asset Accounts

Asset accounts represent anything that's owned.  Typically, these are

primarily your cash accounts, or anything that's completely liquid.

Many accounting tutorial materials will note that Loans, accounts receivable

and other receivables are assets as well.  Most accountants will

say that they are, but with regard to accounts called "Assets", this system

uses the account hierarchy `Assets:` only for tangible, liquid,

cash and/or cash-equivalent assets.  You'll find that account hierarchy

commonly in the examples herein.

### Liabilities Accounts

Similar to assets, most accountants will point out that any amount owed to

someone else is a liability, and that is of course accurate.  Like with the

`Assets:` hierarchy, this system uses `Liabilities:` hierarchy only to refer

to formalized accounts, such as credit cards, where a monthly statement is

sent and have an ongoing liability relationship with the organization.

### Accrued Accounts

For items that are receivable or payable, this system uses `Accrued:`

hierarchy.  Under this top-level account, you'll find accounts payable,

accounts receivable, loans payable and loans receivable.

### Expense Accounts

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

`Expense:`.

### 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.

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.

### Tags Used In This System

A list of tags can be found in the file `accounts/config/config-tags.ledger`

in this project.

#### 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.

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

the repository to the document.

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.

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.

### Expense Account Documentation

Each Expense account entries need to be tagged with an

[`Invoice`](#invoice-tag), [`Receipt`](#receipt-tag), or

[`Statement`](#statement-tag) tag.  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

         Expense: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.

#### payee with "NEVER CHARGED"

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 an

historical special-case.  The solution was originally design 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