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 centers 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: Amortization schedule, cost center, period allocation

Card Transactions

• Type: Card Transaction
• Purpose: Corporate card charges
• Lifecycle: Imported (Authorized), settled, categorized, 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
• Some fields can still be edited, and a change that affects the ledger reverses the original transactions and creates new ones (see Resetting and voiding)
• 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 for most document types. Sales invoices and customer credits are the exception: Restore brings them back to Draft

# 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

The transactions on the ledger are immutable and are never changed or deleted. When a posted document needs correcting, Light reverses and re-posts for you, and the action you use depends on the document type:

• Edit on a posted bill, sales invoice or customer credit opens a limited set of fields and keeps the document Posted. Where a change affects the ledger, Light undoes any clearings, reverses the original transactions, posts new ones and reapplies the clearings, all in one step. Amounts can't be changed this way.
• Modify on a journal entry returns the same entry to Draft, keeping its sequence number, so you can correct it and post it again.
• Reset (or Reset to draft) on a bill, sales invoice or customer credit reverses its postings and returns it to Draft.

The ledger keeps a complete, immutable record of both the original and the corrected transactions. See Resetting and voiding for what each document type offers.

# 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 reversing transactions are dated the original posting date, so the action fails if that period is closed or locked

5. The accounting document itself either returns to Draft, so you can correct and re-post it, or is closed out: Void for most types, Cancelled for bills, and Reversed for an invoice after Reverse and reissue

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

A journal entry in Pending approval or Approved can also go back to Draft with Reset to draft. This cancels the approval so you can edit the entry and submit it again, for example when an account was disabled or the period was locked after it was submitted. Company Admins and Controllers can use it.

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, such as 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

For most document types, archiving a draft and voiding a posted document end in the same Void status. Bills are the exception: archiving a bill ends in Cancelled, with no restore. Discard Bill(s) on the Bills list closes out up to 25 bills at once, and they appear on the Discarded tab.

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. For most document types Void is terminal.

Note: Customer credits and sales invoices are an exception: an archived customer credit or invoice can be restored to Draft with Restore, so archiving one of these by mistake doesn't have to be permanent.

# Document Sequence

Each document type has a sequence:

• Format: DOCTYPE/ENTITY/NUMBER (e.g., AP/001/000000123, where the middle part is the entity's own code and the number is zero-padded to 9 digits)
• Guarantees uniqueness: no two documents have the same number
• Immutable: the sequence number is assigned at first posting and never changes, including when the document is reset or modified
• 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 center
• 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

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