Changeset - 68d036aa0292
[Not reviewed]
0 1 0
Bradley Kuhn (bkuhn) - 10 years ago 2013-04-29 20:27:45
Documentation of Receipt: tag and its appropriate uses.
1 file changed with 29 insertions and 1 deletions:
0 comments (0 inline, 0 general)
Show inline comments
@@ -101,97 +101,125 @@ 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 Accounts

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 entry is included.
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

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

### Expense Account Documentation

Each Expense account entries need to be tagged with an `Invoice`, `Receipt`,
or `Statement` 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
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 the ledger
**until** you had real proof via an Invoice, Receipt or Statement that showed
0 comments (0 inline, 0 general)