Help Center / General Ledger

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.

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 (AP and AR credits)

Each document type has domain-specific fields but follows the same posting lifecycle. Regardless of type, the accounting document itself remains mutable—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: The invoice date on the bill is used as the posting date when the document posts to the ledger. This means the invoice date must fall within an open accounting period for the bill to be posted. If you need to track a separate received date (e.g., when the invoice was received vs. the date on the invoice), you can create 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 (Pending), 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. While a transaction is in Pending 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 (AP) or Customer Credit (AR)
  • Purpose: Offset original invoices (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 → (APPROVAL_PENDING → APPROVED) → POSTED → (PARTIALLY_CLEARED) → CLEARED

ARCHIVED (terminal)

Documents that require approval pass through APPROVAL_PENDING and APPROVED before posting; documents without an approval workflow post directly from DRAFT.

DRAFT State:

  • Document is being created or edited
  • Can be modified freely (amounts, lines, etc.)
  • Has not posted to the ledger yet
  • Not visible in financial reports

APPROVAL_PENDING State:

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

APPROVED State:

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

POSTED State:

  • Accounting document has posted to the ledger
  • One or many immutable GL transactions have been created
  • The accounting document can still be edited—the system automatically 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 State:

  • Document has been partially matched/cleared
  • Some GL transactions matched to other documents
  • Can still be modified (reversals are uncleared first)
  • Shows in aged item reports

CLEARED State:

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

ARCHIVED State:

  • Document marked as closed/inactive
  • Removed from active document lists
  • Remains in system for historical/audit purposes
  • Terminal status—an archived document cannot be reactivated

Posting Process

When a document posts to the ledger:

  1. Validation - System validates all required fields and amounts
  2. Sequence number assignment - Unique document sequence ID generated
  3. Line expansion - Multi-line documents expanded into individual GL entries
  4. Tax calculation - Tax amounts calculated and posted to tax accounts
  5. FX conversion - Multi-currency amounts converted to local/group currencies
  6. GL posting - All entries posted to ledger_transaction_line table as immutable transactions
  7. Status change - Document status changes from DRAFT (or APPROVED) to POSTED

Posting is atomic—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.

Good to know: Posting typically takes 1-5 seconds. For bulk operations, timing may vary.

Modifying Posted Documents

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

  1. Document status must be POSTED, PARTIALLY_CLEARED, or CLEARED
  2. Click Modify
  3. System automatically:
    • Reverses all clearings and matched entries
    • Reverses the original immutable transactions (creates 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's atomic—all steps succeed or all fail.

Reversing Documents

To completely undo a posting:

  1. Open the document
  2. Click Reverse
  3. System posts reversing transactions with opposite amounts:
    • All debits become credits, all credits become debits
    • Same GL accounts, amounts, and descriptions
    • Each reversing transaction is linked to the original transaction it reverses, for audit trail
  4. Original transactions remain in the ledger; the reversing transactions offset them. The accounting document itself is either returned to DRAFT (so it can be corrected and re-posted) or archived (voided)

Reversals are used when you want to document that an error occurred (for audit trail).

Note: If a document has been cleared or partially cleared (e.g., a bill with linked payments or credit notes), you must reverse those linked entries first before reversing the original document. The system requires the document to be in POSTED status before it can be reversed. If you attempt to reverse a document in PARTIALLY_CLEARED or CLEARED status, you'll see an error prompting you to reverse the linked entries 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 but doesn't modify either—they remain as posted.

Workflow Integration

Many documents require approval before posting:

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

Approval workflows control who can post what documents.

Bulk Operations

Light supports bulk posting of documents:

  1. Create multiple documents in draft
  2. Select them and click Post All
  3. Each document validates and posts
  4. Progress shown, with success/failure breakdown
  5. Failed documents remain in DRAFT for correction

Bulk posting is faster than posting individually but should be done carefully.

Archival

Draft documents that are no longer needed can be archived:

  1. Click Archive on a draft document
  2. Document is hidden from active lists
  3. Remains in the system for reporting/audit

Only documents in DRAFT status can be archived directly. A posted document reaches ARCHIVED status by being reversed (voided) without being returned to draft. ARCHIVED is a terminal status—archived 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 - Sequence number assigned at posting, never changes
  • Supports reporting - Easy reference to specific documents

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/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 - Posting date's period must not be closed
  • Approval complete - If applicable, approval workflow must be done
  • Business rules - Document-type-specific rules

Validation prevents invalid data from reaching the ledger.

Was this article helpful?

Book a demo