Accounting Document Types and Lifecycle

All financial activity in Light flows through a unified accounting document system. Accounting documents are mutable records that can be edited throughout their lifecycle. When posted, each accounting document generates one or many immutable transactions on the general ledger. This article explains the document types and their lifecycle from creation to archival.

# What is this page about

This page covers the ten accounting document types in Light, the statuses each one moves through, and what happens when you post, modify, reverse, or void one. Read it to understand why a posted document can still be edited while your ledger stays immutable.

On this page

• Accounting Document Concept
• Document Structure
• Document Types
• Document Lifecycle
• Posting Process
• Modifying Posted Documents
• Reversing Documents
• Clearing and Matching
• Workflow Integration
• Bulk Operations
• Archival
• Document Sequence
• Multi-Line Documents
• Custom Properties
• Document Validation
• Related Articles

# Accounting Document Concept

An accounting document is a mutable record that, when posted, generates one or many immutable transactions on the general ledger. The following are all types of accounting documents:

• Invoice Payables (vendor bills)
• Invoice Receivables (customer invoices)
• Bank Payments (payment instructions)
• Journal Entries (manual GL entries)
• Card Transactions (corporate card charges)
• Deferred Entries (accruals and deferrals)
• FX Revaluations (currency adjustments)
• Year-End Closing Entries (period close entries)
• Credit Notes (offset an Invoice Payable)
• Customer Credits (offset an Invoice Receivable)

Each document type has domain-specific fields but follows the same posting lifecycle. Regardless of type, the accounting document itself remains mutable, so you can edit it at any stage, while the transactions it generates on the ledger are always immutable.

# Document Structure

All documents share a common structure:

Header:

• Unique ID and sequence number
• Document type and status
• Company entity (which entity it belongs to)
• Posting date (when it posts to GL)
• Document date (when the transaction occurred)
• Currency and amount
• Business partner (if applicable: vendor, customer)

Lines:

• GL account and amount for each line
• Tax information if applicable
• Allocation to cost centres or projects
• Custom properties

Relationships:

• Linked to source documents (purchase order, contract)
• Linked to cleared/matched documents
• Linked to workflow approvals

# Document Types

Accounts Payable (AP)

• Type: Invoice Payable
• Purpose: Vendor invoices for goods/services received
• Lifecycle: Created, approved, posted, paid, cleared
• Key fields: Vendor, invoice number, due date, payment terms
• Posting date: Posting date is its own field on the bill, independent of the invoice date (it defaults to today if not otherwise set). This posting date, not the invoice date, must fall within an open accounting period for the bill to post. If you need to track the invoice date separately from when it's posted (or the date it was received), you can use the invoice date field and/or a custom property date field on the bill header.

Accounts Receivable (AR)

• Type: Invoice Receivable
• Purpose: Customer invoices for goods/services sold
• Lifecycle: Created, sent, posted, payment received, cleared
• Key fields: Customer, contract, billing period, payment terms

Bank Payments

• Type: Bank Payment
• Purpose: Payment instructions sent to the bank
• Lifecycle: Created, approved, posted, executed, cleared
• Key fields: Bank account, payment method, payee, amount

Journal Entries

• Type: Journal Entry
• Purpose: Manual GL entries for adjustments, accruals, etc.
• Lifecycle: Created, posted, cleared (if matched to transactions)
• Key fields: GL accounts, debit/credit amounts, description

Deferred Entries

• Type: Deferred Entry
• Purpose: Accruals, deferrals, and spreading costs over time
• Lifecycle: Template created, entries generated, posted
• Key fields: Amortisation schedule, cost centre, period allocation

Card Transactions

• Type: Card Transaction
• Purpose: Corporate card charges
• Lifecycle: Imported (Authorized), settled, categorised, posted, cleared
• Key fields: Cardholder, merchant, category, amount
• Posting date: Card transactions can only be posted after the merchant has settled the transaction with the card network (posting is blocked unless the transaction has been captured or refunded). While a transaction is in Authorized status, posting is not possible because the merchant may still adjust the final amount. Once settled (typically 1-3 business days), the transaction can be posted to the GL.

Credit Notes

• Type: Credit Note (CN)
• Purpose: Offset an original Invoice Payable (vendor refunds, adjustments)
• Lifecycle: Created, posted, matched to invoice
• Key fields: Original invoice reference, credit reason, amount

Customer Credits

• Type: Customer Credit (CC)
• Purpose: Offset an original Invoice Receivable (customer refunds, adjustments)
• Lifecycle: Created, posted, matched to invoice
• Key fields: Original invoice reference, credit reason, amount

FX Revaluations

• Type: FX Revaluation
• Purpose: Currency adjustment entries
• Lifecycle: Generated, posted, cleared
• Key fields: Asset accounts, exchange rates, currency pairs

Year-End Closing

• Type: Year Closing Entry
• Purpose: Transfer net income to retained earnings
• Lifecycle: Generated at year-end, posted, never reversed
• Key fields: Earnings accounts, retained earnings account

# Document Lifecycle

All documents follow this state machine:

Draft → (Pending approval → Approved) → Posted → (Partially cleared) → Cleared

Void (terminal)

Documents that require approval pass through Pending approval and Approved before posting. Documents without an approval workflow post directly from Draft.

Draft:

• Document is being created or edited
• Can be modified freely (amounts, lines, etc.)
• Has not posted to the ledger yet
• Stays out of your financial reports

Pending approval:

• Document has been submitted for approval
• Awaiting completion of the approval workflow before it can be posted

Approved:

• Approval workflow has completed successfully
• Document is ready to be posted

Posted:

• Accounting document has posted to the ledger
• One or many immutable GL transactions have been created
• The accounting document can still be edited, and Light reverses the original transactions and creates new ones (see Immutable ledger and audit trail)
• Visible in financial reports
• Can be cleared as transactions are matched

Partially cleared:

• Document has been partially matched or cleared
• Some GL transactions matched to other documents
• Can still be modified, with reversals uncleared first
• Shows in aged item reports

Cleared:

• Document fully matched to other documents
• All amounts have been reconciled
• Can still be modified if needed
• Typically no longer needs attention

Void:

• Document marked as closed and inactive
• Removed from active document lists
• Remains in the system for historical and audit purposes
• A terminal status, so a voided document cannot be reactivated

# Posting Process

When a document posts to the ledger:

1. Validation: Light validates all required fields and amounts
2. Sequence number assignment: a unique document sequence ID is generated
3. Line expansion: multi-line documents expand into individual GL entries
4. Tax calculation: tax amounts are calculated and posted to tax accounts
5. FX conversion: multi-currency amounts convert to local and group currencies
6. GL posting: all entries post to the ledger as immutable transactions
7. Status change: the document moves from Draft or Approved to Posted

Posting is atomic, so either all transactions post or none do. Partial posts are not possible. Once posted, the resulting transactions on the ledger are immutable and cannot be edited or deleted.

# Modifying Posted Documents

Because accounting documents are mutable, you can edit them even after posting. The transactions on the ledger, however, are immutable, and are never changed or deleted. Instead, the accounting document engine handles corrections for you:

1. The document must be in Posted, Partially cleared, or Cleared status

2. Click Modify

3. Light then:

   • Reverses all clearings and matched entries
   • Reverses the original immutable transactions, creating new offsetting entries
   • Applies your modifications to the accounting document
   • Posts new immutable transactions with the updated amounts
   • Reapplies clearings

4. The accounting document now reflects your changes, and the ledger contains a complete, immutable record of both the original and corrected transactions

Modifying is safer than manual reversals because it is atomic, so all steps succeed or all fail.

# Reversing Documents

To completely undo a posting:

1. Open the document

2. Choose the reversing action. Its label depends on the document type: a journal entry offers Void, a sales invoice offers Reverse and reissue as well as Archive, and bills, credit notes and customer credits offer Archive

3. Light posts reversing transactions with opposite amounts:

   • All debits become credits, all credits become debits
   • Same GL accounts, amounts, and descriptions
   • Each reversing transaction links to the original transaction it reverses, for the audit trail

4. Original transactions remain in the ledger and the reversing transactions offset them. The accounting document itself either returns to Draft, so you can correct and re-post it, or moves to Void

Reversals are used when you want to document that an error occurred, which keeps the audit trail clear.

Note: A document must be in Posted status before it can be reversed. Attempting to reverse a document in Partially cleared or Cleared status returns an error saying the document cannot be reversed in its current status. Undo the clearing or matching on the document first.

# Clearing and Matching

Documents can be "cleared" when matched to other documents:

Bank reconciliation:

• Bank transaction matched to GL payment entry
• Both marked as cleared/matched

Invoice payment:

• AP invoice matched to payment
• Both show cleared status

Cross-entity settlements:

• Intercompany payable matched to intercompany receivable
• Both cleared

Clearing links documents without modifying either, so both remain as posted.

# Workflow Integration

Many documents require approval before posting:

1. Document created in Draft status
2. Submitted for approval (status changes to Pending approval)
3. Approval workflow completes (approved or rejected)
4. If approved, the status changes to Approved and the document can be posted
5. If rejected, the document returns to Draft for modification

Approval workflows control who can post what documents.

# Bulk Operations

Card transactions support a batch-post action, so you can post many card transactions together in one step. Other accounting documents — bills, invoices, and journal entries — post one at a time; there is no "Post All" bulk-posting action for them.

# Archival

Draft documents that are no longer needed can be voided:

1. On the document, choose Archive, or Void on a journal entry
2. The document is hidden from active lists
3. It remains in the system for reporting and audit

Underneath, archiving a draft and voiding a posted document are the same operation, and both leave the document in Void status. Only the button wording differs between document types.

Documents in Draft status can be voided directly. A posted document can also reach Void through reversal, and depending on how the reversal is performed a reversed document either returns to Draft or moves to Void. Void is a terminal status, so voided documents cannot be reactivated.

# Document Sequence

Each document type has a sequence:

• Format: DOCTYPE/ENTITY/NUMBER (e.g., AP/001/000000123, with the number zero-padded to 9 digits)
• Guarantees uniqueness: no two documents have the same number
• Immutable: the sequence number is assigned at posting and never changes
• Supports reporting: gives you an easy reference to a specific document

Sequences are maintained per document type and per company entity (e.g., each entity's APs have their own sequence, separate from its JEs).

# Multi-Line Documents

Documents can have multiple line items:

Invoice example:

• Header: Invoice, total amount, vendor
• Line 1: Materials, GL account, amount, tax
• Line 2: Labor, GL account, amount, tax
• Line 3: Shipping, GL account, amount, tax

When posted, each line posts to its GL account, creating multiple immutable ledger transactions. A single accounting document can therefore generate many transactions on the general ledger.

# Custom Properties

Documents can be tagged with custom properties:

• Department, project, cost centre
• Program, activity, fund
• Custom fields you define

Custom properties are posted with each GL transaction for reporting and analysis.

# Document Validation

Before posting, documents are validated:

• Required fields: all required fields must be filled
• Amount balance: debits must equal credits
• GL accounts exist: all accounts must be valid
• Period is open: the posting date's period must be open
• Approval complete: where applicable, the approval workflow must be done
• Business rules: document-type-specific rules

Validation prevents invalid data from reaching the ledger.

# Related Articles

• Understanding Light's general ledger
• Viewing and searching journal entries
• Creating manual journal entries
• Immutable ledger and audit trail