NPO-Accounting/npo-ledger-cli Changeset - c9fc4a8761cd

Changeset - c9fc4a8761cd

Parent rev.

Child rev.

[Not reviewed]

0 1 0

Bradley Kuhn (bkuhn) - 11 years ago 2013-04-29 20:30:49
bkuhn@ebb.org

Initial documentation of the Invoice: tag.

1 file changed with 19 insertions and 0 deletions:

npo-ledger-cli-tutorial.md

0 comments (0 inline, 0 general)

npo-ledger-cli-tutorial.md

➞

Show inline comments

@@ ... @@
 "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 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).
 ### 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:
 -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 &mdash; for example, a situation where you
 gave a credit card number to charge something and the charge never came
 through &mdash; 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:
 /05/28 My Bad Billing Hosting - NEVER CHARGED
         Liabilities:Credit Card:Visa            $-100.00
         Expenses:Conservancy:Hosting             $100.00
 /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
 the Expense did/should occur.  This use of `NEVER CHARGED` in the payee is

0 comments (0 inline, 0 general)