Purpose of This Entry Type in ERPNext

1. Inter Company Journal Entry

The Inter Company Journal Entry is specifically designed for recording transactions between different companies within the same ERPNext instance. 1

Why this Entry Type exists:

• To facilitate inter-company transactions (expenses, transfers, or adjustments) between sister companies
• To maintain proper audit trail and linked accounting records across multiple legal entities
• To enable automatic creation of mirror entries in the counterpart company

Business situations where ERPNext expects this type:

• Shared service charges between group companies
• Inter-company loans or advances
• Cost allocations across business units operating as separate companies
• Management fees or royalty payments within corporate groups

What ERPNext treats differently:
When this voucher type is selected, ERPNext enables a special “Create Inter Company Journal Entry” button after submission that allows you to create a linked journal entry in another company. 2

System Behavior Triggered by This Entry Type

Special Logic Enabled:

1. Inter-Company Linking: On submission, the system updates the inter_company_journal_entry_reference field to create bidirectional references between the two journal entries. 3
2. Currency Validation: When two companies use the same currency, ERPNext validates that the total debit/credit amounts match between linked entries. The system ensures that one company’s debit equals the other company’s credit and vice versa. 4
3. Unlinking on Cancellation: When either journal entry is cancelled, the system automatically clears the inter-company reference from both documents. 5

Form Behavior:

• The “Create Inter Company Journal Entry” button appears only when the voucher type is “Inter Company Journal Entry”, the document is submitted, and no reference exists yet
• The system provides a dialog to select the target company

Real-Life ERPNext Example (End-to-End)

Scenario: Company A (_Test Company) provides IT support services to Company B (_Test Company 1) for ₹100,000.

Step-by-Step Entry Process:

In Company A (_Test Company):

1. Create new Journal Entry
2. Select Entry Type: “Inter Company Journal Entry”
3. Set Posting Date: Current date
4. Add accounting entries:

• Row 1 (Debit):
  • Account: Buildings – _TC (Asset account)
  • Debit: ₹100,000
  • Cost Center: Main – _TC
• Row 2 (Credit):
  • Account: Sales Expenses – _TC (Expense account)
  • Credit: ₹100,000
  • Cost Center: Main – _TC

1. Set multi_currency = 0 (same currency transaction)
2. Submit the document

Create Linked Entry in Company B:

7. Click Make → Create Inter Company Journal Entry
8. Select Company: “_Test Company 1”
9. System auto-populates a new Journal Entry with:

• Entry Type: “Inter Company Journal Entry”
• Reversed accounts for Company B
• Reference to Company A’s journal entry

7. Adjust accounts to Company B’s chart of accounts:
   • Buildings – _TC1 (Debit ₹100,000)
   • Sales Expenses – _TC1 (Credit ₹100,000)
8. Submit Company B’s journal entry
9. System automatically links both entries bidirectionally 6

---

2. Bank Entry

Purpose of This Entry Type in ERPNext

The Bank Entry is the standard voucher type for all transactions involving bank accounts – whether receipts from customers, payments to suppliers, or bank-related adjustments.

Why this Entry Type exists:

• To properly classify and track all banking transactions
• To enable bank reconciliation features
• To enforce mandatory reference number and date requirements for audit compliance

Business situations where ERPNext expects this type:

• Customer payment receipts via bank transfer/check
• Supplier payments through bank accounts
• Bank charges, interest income, or bank fees
• Any transaction where a bank account is debited or credited

What ERPNext treats differently:
The system mandates entry of cheque/reference number and date for Bank Entry types to maintain proper documentation. 7

System Behavior Triggered by This Entry Type

Special Validations Activated:

1. Mandatory Cheque Information: The system validates that both cheque_no (Reference Number) and cheque_date (Reference Date) are provided before submission. 8
2. Auto-Population of Bank Account: When voucher type is changed to “Bank Entry”, the system automatically calls get_default_bank_cash_account() to populate the default bank account from Company master if no accounts exist yet. 9
3. Default Bank Account Logic: The system first checks the company’s default_bank_account. If not set, it searches for a single non-group Bank account. If multiple exist, it leaves the selection to the user. 10

Form Changes:

• Reference Number and Reference Date fields become mandatory (marked with red asterisk)
• If accounts table is empty or has only one blank row, system auto-adds the default bank account

Real-Life ERPNext Example (End-to-End)

Scenario: Receive customer payment of ₹50,000 via bank transfer with reference number “TXN123456”.

Step-by-Step Entry Process:

1. Navigate to Accounting → Journal Entry → New
2. Select Entry Type: “Bank Entry”
3. Set Company: “_Test Company”
4. Set Posting Date: Today’s date
5. Enter Reference Number: “TXN123456”
6. Enter Reference Date: Transaction date (mandatory)
7. Add accounting entries:

• Row 1 (Debit – Bank):
  • Account: “_Test Bank – _TC” (Account Type: Bank)
  • Debit in Account Currency: ₹50,000
  • Cost Center: Main – _TC
• Row 2 (Credit – Customer):
  • Account: “Debtors – _TC” (Account Type: Receivable)
  • Party Type: Customer
  • Party: “_Test Customer”
  • Credit in Account Currency: ₹50,000
  • Cost Center: Main – _TC
  • Reference Type: Sales Invoice (if against invoice)
  • Reference Name: SINV-0001

1. System creates automatic remark mentioning the reference number and date 11
2. Verify Total Debit = Total Credit = ₹50,000
3. Save and Submit

---

3. Cash Entry

Purpose of This Entry Type in ERPNext

The Cash Entry is specifically designed for all transactions involving cash accounts – petty cash, cash-in-hand, or cash registers.

Why this Entry Type exists:

• To properly track cash movements and maintain cash books
• To distinguish cash transactions from bank transactions for reporting
• To enable proper cash reconciliation and physical cash verification

Business situations where ERPNext expects this type:

• Cash sales receipts
• Petty cash expenses
• Cash payments to suppliers
• Employee expense reimbursements in cash
• Daily cash deposits to bank

What ERPNext treats differently:
Similar to Bank Entry, the system automatically populates the default cash account when this type is selected.

System Behavior Triggered by This Entry Type

Special Logic Enabled:

1. Auto-Population of Cash Account: When voucher type is changed to “Cash Entry”, ERPNext automatically calls get_default_bank_cash_account() with account_type=”Cash” to fetch and populate the default cash account. 12
2. Default Cash Account Detection: The system checks the company’s default_cash_account. If not configured, it looks for a single non-group Cash account in the chart of accounts. 13
3. Account Balance Display: The system can optionally fetch and display the current balance of the cash account. 14

Form Behavior:

• If no accounts are present, the default cash account is automatically added to the first row
• Unlike Bank Entry, reference number and date are optional for cash transactions

Real-Life ERPNext Example (End-to-End)

Scenario: Pay office rent of ₹25,000 in cash to the landlord.

Step-by-Step Entry Process:

1. Create new Journal Entry
2. Select Entry Type: “Cash Entry”
3. Set Company: “_Test Company”
4. Set Posting Date: Payment date
5. Enter User Remark: “Monthly rent payment for January 2024”
6. Add accounting entries:

• Row 1 (Debit – Expense):
  • Account: “Rent – _TC” (Account Type: Expense, Root Type: Expense)
  • Debit in Account Currency: ₹25,000
  • Cost Center: Main – _TC
• Row 2 (Credit – Cash):
  • Account: “_Test Cash – _TC” (Account Type: Cash)
  • Credit in Account Currency: ₹25,000
  • Cost Center: Main – _TC

1. Optionally enter Pay To / Received From: Landlord name for printing
2. Verify balancing: Total Debit = Total Credit = ₹25,000
3. Save and Submit
4. Print cash payment voucher for landlord’s signature

---

4. Credit Card Entry

Purpose of This Entry Type in ERPNext

The Credit Card Entry is designed to record transactions made through corporate credit cards or credit card payment processing.

Why this Entry Type exists:

• To track credit card expenses separately from bank and cash
• To facilitate credit card statement reconciliation
• To manage credit card liabilities until payment is made
• To record credit card payment processing fees

Business situations where ERPNext expects this type:

• Corporate credit card expenses by employees
• Online payment gateway transactions (credit card processing)
• Credit card bill payments
• Credit card refunds from vendors
• Merchant discount rate (MDR) entries

What ERPNext treats differently:
While no special validation is enforced at the code level for Credit Card Entry, this voucher type serves as a classification mechanism for reporting and reconciliation purposes. 15

System Behavior Triggered by This Entry Type

Standard Journal Entry Behavior:

Unlike Bank Entry or Cash Entry, Credit Card Entry does not trigger automatic account population or mandatory field validations. It follows standard journal entry processing with these characteristics:

1. No Mandatory Reference Fields: Reference number and date are optional (unlike Bank Entry)
2. Standard Validation: All standard journal entry validations apply – debit must equal credit, accounts must balance
3. Multi-Currency Support: Credit card accounts in foreign currencies are fully supported
4. Classification Only: The primary purpose is to classify entries for reporting and bank reconciliation

Form Behavior:

• No automatic account population
• No special field requirements
• Standard journal entry interface with all features available

Real-Life ERPNext Example (End-to-End)

Scenario: Record corporate credit card expense of ₹15,000 for purchasing office supplies.

Step-by-Step Entry Process:

1. Create new Journal Entry
2. Select Entry Type: “Credit Card Entry”
3. Set Company: “_Test Company”
4. Set Posting Date: Transaction date
5. Enter Reference Number: Last 4 digits of transaction (e.g., “CC-1234”)
6. Enter User Remark: “Office supplies purchased via corporate card”
7. Add accounting entries:

• Row 1 (Debit – Expense):
  • Account: “Office Supplies – _TC” (Account Type: Expense)
  • Debit in Account Currency: ₹15,000
  • Cost Center: Main – _TC
• Row 2 (Credit – Credit Card Liability):
  • Account: “Credit Card – _TC” (Account Type: Bank or Liability)
  • Credit in Account Currency: ₹15,000
  • Cost Center: Main – _TC

1. Verify totals match
2. Save and Submit

When Credit Card Bill is Paid:

10. Create another Journal Entry (Entry Type: “Bank Entry”)
11. Debit: Credit Card – _TC (clearing the liability)
12. Credit: Bank Account (actual payment)

---

5. Debit Note

Purpose of This Entry Type in ERPNext

The Debit Note entry type is used for recording adjustments that increase a supplier’s liability or decrease a customer’s receivable in the books. This is the manual journal entry equivalent of a Purchase Return.

Why this Entry Type exists:

• To record purchase returns when goods are returned to suppliers
• To record additional charges claimed from suppliers (quality issues, shortages)
• To adjust supplier accounts for price corrections
• To enable Tax Deducted at Source (TDS) functionality on supplier transactions

Business situations where ERPNext expects this type:

• Purchase returns (goods sent back to supplier)
• Price disputes resulting in adjustments
• Quality rejection adjustments
• Shortage claims against suppliers
• TDS deduction entries requiring tax withholding calculation

What ERPNext treats differently:
When Debit Note is selected with the apply_tds checkbox enabled, ERPNext automatically calculates and applies tax withholding (TDS) based on the configured Tax Withholding Category. 16

System Behavior Triggered by This Entry Type

Tax Withholding Automation:

1. TDS Calculation Activation: When voucher_type = "Debit Note" and apply_tds = 1, the system invokes the JournalEntryTaxWithholding class to automatically calculate tax withholding. 17
2. Automatic TDS Row Creation: The system calculates the net total from non-tax accounts, applies the tax withholding rate from the Tax Withholding Category, and automatically creates or updates a TDS account row with credit entry (government liability). 18
3. Supplier Account Adjustment: The system automatically reduces the supplier’s credit amount by the TDS amount, reflecting that net payment to supplier will be less than gross amount. 19
4. Single Party Validation: The system throws an error if multiple suppliers/parties are present in a single Debit Note when TDS is applied. 20

Invoice Validation Behavior:

When a Debit Note references Sales or Purchase Invoices, ERPNext validates that the invoice is submitted and has sufficient outstanding amount, but this validation is skipped for Debit/Credit Note types. 21

Real-Life ERPNext Example (End-to-End)

Scenario: Return defective goods worth ₹100,000 to supplier with 10% TDS applicable.

Step-by-Step Entry Process:

1. Create new Journal Entry
2. Select Entry Type: “Debit Note”
3. Set Company: “_Test Company”
4. Set Posting Date: Return date
5. Check Apply TDS checkbox
6. Select Tax Withholding Category: “TDS – 194Q” (assuming 10% rate configured)
7. Enter User Remark: “Return of defective goods – Inv No XYZ”
8. Add accounting entries:

• Row 1 (Debit – Supplier Account):
  • Account: “Creditors – _TC” (Account Type: Payable)
  • Party Type: Supplier
  • Party: “_Test Supplier”
  • Debit in Account Currency: ₹100,000
  • Cost Center: Main – _TC
  • Reference Type: Purchase Invoice
  • Reference Name: PINV-0001
• Row 2 (Credit – Purchase Returns):
  • Account: “Purchase Returns – _TC” (Account Type: Expense)
  • Credit in Account Currency: ₹100,000
  • Cost Center: Main – _TC

1. System automatically adds TDS row:

• Row 3 (Credit – TDS Payable – Auto-created):
  • Account: “TDS Payable – _TC” (Account Type: Tax)
  • Credit: ₹10,000 (10% of ₹100,000)
  • Cost Center: Main – _TC
  • is_tax_withholding_account: 1

1. System automatically adjusts Row 1:
   • Supplier Debit reduces to: ₹90,000 (₹100,000 – ₹10,000 TDS)
2. Verify totals: Debit ₹90,000 = Credit ₹90,000 (₹100,000 – ₹10,000 TDS)
3. Save and Submit
4. Result: Supplier liability reduced by ₹90,000 net, TDS liability of ₹10,000 created

---

6. Credit Note

Purpose of This Entry Type in ERPNext

The Credit Note entry type is used for recording adjustments that decrease a customer’s receivable or increase a supplier’s liability. This is the manual journal entry equivalent of a Sales Return.

Why this Entry Type exists:

• To record sales returns when customers return goods
• To provide discounts or price adjustments to customers
• To write off bad debts or unrecoverable amounts
• To enable Tax Collected at Source (TCS) functionality on customer transactions

Business situations where ERPNext expects this type:

• Sales returns (goods returned by customers)
• Post-sale discounts or price corrections
• Damaged goods credit notes
• Customer goodwill adjustments
• TCS collection entries

What ERPNext treats differently:
When Credit Note is selected with apply_tds checkbox enabled, ERPNext automatically calculates and applies Tax Collected at Source (TCS) based on the configured Tax Withholding Category for customers. 16

System Behavior Triggered by This Entry Type

Tax Collection Automation:

1. TCS Calculation Activation: Similar to Debit Note but for customers, when voucher_type = "Credit Note" and apply_tds = 1, the system calculates TCS (Tax Collected at Source). 22
2. Direction Reversal for Customer: For Credit Notes with customers, the tax direction is reversed – TCS increases the customer’s debit (they owe more including tax), unlike TDS which reduces supplier credit. 23
3. Automatic TCS Row Creation: The system creates a credit entry in the TCS account (government liability) and increases the customer’s debit accordingly.
4. Stock Entry Validation: If a stock entry is linked to the Credit Note, the system validates that the stock entry is submitted before allowing the journal entry to proceed. 24

Invoice Reference Handling:

Credit Notes can reference Sales Invoices for returns, and ERPNext skips the outstanding amount validation that normally applies to payment entries. 21

Real-Life ERPNext Example (End-to-End)

Scenario: Customer returns goods worth ₹50,000 due to quality issues. Stock Entry already created for returned goods.

Step-by-Step Entry Process:

1. First, create Stock Entry for goods receipt (return)

• Stock Entry Type: Material Receipt
• Purpose: Sales Return
• Submit the Stock Entry (e.g., STE-0001)

1. Create new Journal Entry
2. Select Entry Type: “Credit Note”
3. Set Company: “_Test Company”
4. Set Posting Date: Return date
5. Select Stock Entry: “STE-0001” (links to the stock movement)
6. Enter User Remark: “Customer return – quality issue”
7. Add accounting entries:

• Row 1 (Debit – Sales Returns):
  • Account: “Sales Returns – _TC” (Account Type: Income)
  • Debit in Account Currency: ₹50,000
  • Cost Center: Main – _TC
• Row 2 (Credit – Customer Account):
  • Account: “Debtors – _TC” (Account Type: Receivable)
  • Party Type: Customer
  • Party: “_Test Customer”
  • Credit in Account Currency: ₹50,000
  • Cost Center: Main – _TC
  • Reference Type: Sales Invoice
  • Reference Name: SINV-0001

1. Verify totals: Debit ₹50,000 = Credit ₹50,000
2. Save and Submit
3. Result: Customer receivable reduced by ₹50,000, sales returns recorded

With TCS (if applicable):

If TCS of 1% is configured:

• System auto-adds TCS row with Credit ₹500
• Customer Credit adjusts to ₹50,500
• TCS Payable account credited ₹500
• Final balance: Debit ₹50,000 = Credit ₹50,500 (₹50,000 + ₹500 TCS)

---

7. CONTRA ENTRY

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Contra Entry is specifically designed for internal transfers between bank and cash accounts (both balance sheet accounts). 1

Business Situations Where ERPNext Expects This Type:

• Cash withdrawal from bank to office petty cash
• Bank deposit of cash collected at office/retail counters
• Internal fund transfers between different bank accounts
• Movement of cash between different cash registers

What ERPNext Treats Differently:
Unlike other journal entries, Contra Entry is meant exclusively for Bank and Cash account types. ERPNext recognizes this as a balance sheet-to-balance sheet movement with no impact on income or expenses.

System Behavior Triggered by This Entry Type

Logic and Restrictions:
While ERPNext does not enforce strict validation that accounts must be Bank or Cash types for Contra Entry, the naming convention and standard usage pattern indicate this entry type should involve:

• One account of type “Bank”
• One account of type “Cash”
• Or both accounts of the same type for transfers

Form Behavior:
No special form fields appear or get hidden when selecting Contra Entry. The standard journal entry accounts table remains unchanged. 2

Validation Notes:
The system does not automatically validate account types for Contra Entry, but best practice dictates using only Bank and Cash accounts.

Real-Life ERPNext Example (End-to-End)

Scenario: Company withdraws ₹50,000 from HDFC Bank to office petty cash for daily operational expenses.

Why Contra Entry is Chosen:
This is an internal transfer between two balance sheet accounts (Bank → Cash), with no third party involved and no profit/loss impact.

Accounts Used:

Account	Account Type	Debit	Credit	Root Type
Petty Cash – TC	Cash	50,000	0	Asset
HDFC Bank – TC	Bank	0	50,000	Asset

Step-by-Step Entry in ERPNext:

1. Navigate to: Accounting → Journal Entry → New
2. Set Entry Type: Contra Entry
3. Set Posting Date: Current date
4. Set Company: Your Company
5. In Accounts table, add first row:

• Account: Petty Cash – TC
• Debit in Account Currency: 50000
• Cost Center: Main – TC (or appropriate cost center)

1. Add second row:

• Account: HDFC Bank – TC
• Credit in Account Currency: 50000
• Cost Center: Main – TC

1. System automatically calculates:

• Total Debit: 50,000
• Total Credit: 50,000
• Difference: 0

1. Save and Submit

GL Entry Result:

• Petty Cash increases by ₹50,000 (Debit)
• HDFC Bank decreases by ₹50,000 (Credit)
• Balance sheet remains balanced

---

8. EXCISE ENTRY

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Excise Entry is a legacy entry type retained in ERPNext for backward compatibility with older Indian tax regulations (pre-GST era). 1

Business Situations Where ERPNext Expects This Type:
Historically used for:

• Recording excise duty payments to government
• Excise duty collections on manufactured goods
• Adjustments to excise duty accounts
• CENVAT credit entries (India-specific)

What ERPNext Treats Differently:
ERPNext does not apply any special logic or validation when Excise Entry is selected. It functions identically to a standard Journal Entry.

System Behavior Triggered by This Entry Type

Logic and Restrictions:
No special system behavior is triggered. 3

Form Changes:
No fields are hidden or shown specifically for Excise Entry.

Validation:
Standard journal entry validations apply:

• Total debit must equal total credit
• Account selection rules remain unchanged
• No excise-specific validations exist

Real-Life ERPNext Example (End-to-End)

Scenario: Manufacturing company records excise duty payment of ₹25,000 to the government.

Why Excise Entry is Chosen:
For record-keeping and audit trail purposes, to clearly identify excise-related transactions (though “Journal Entry” type would work identically).

Accounts Used:

Account	Account Type	Debit	Credit	Root Type
Excise Duty Payable	Liability	25,000	0	Liability
Bank Account	Bank	0	25,000	Asset

Step-by-Step Entry:

1. Create new Journal Entry
2. Set Entry Type: Excise Entry
3. Set Posting Date and Company
4. Add accounts:

• Debit: Excise Duty Payable – 25,000
• Credit: Bank Account – 25,000

1. Add Reference Number and Reference Date if payment via cheque
2. Save and Submit

Note: With GST implementation in many countries, this entry type is rarely used in modern ERPNext implementations.

---

9. WRITE OFF ENTRY

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Write Off Entry provides a systematic way to write off uncollectible receivables or unpayable obligations in bulk, with a helper function to fetch outstanding invoices. 4

Business Situations Where ERPNext Expects This Type:

• Customer debts deemed uncollectible after all recovery attempts
• Small outstanding amounts where collection cost exceeds value
• Supplier credits that cannot be utilized (expired/small amounts)
• Bad debt provisioning at year-end

What ERPNext Treats Differently:
When Write Off Entry is selected, ERPNext activates special UI elements and helper functions not available in standard journal entries.

System Behavior Triggered by This Entry Type

Logic and Restrictions:
When “Write Off Entry” is selected, the system displays: 5

1. Write Off Based On field (Options: Accounts Receivable / Accounts Payable)
2. Write Off Amount field (to filter invoices below threshold)
3. Get Outstanding Invoices button

Button Functionality:
Clicking “Get Outstanding Invoices” triggers get_outstanding_invoices() method which: 6

• Queries submitted Sales/Purchase Invoices with outstanding_amount > 0
• Filters by write_off_amount if specified
• Auto-populates accounts table with:
• Party details (Customer/Supplier)
• Outstanding amounts
• Reference to original invoice

Form Changes:
The “Write Off” section appears with dependency: eval:doc.voucher_type == 'Write Off Entry'

Real-Life ERPNext Example (End-to-End)

Scenario: Company decides to write off small customer outstanding balances below ₹5,000 at year-end.

Why Write Off Entry is Chosen:
To systematically identify and write off multiple small outstanding invoices in a single transaction using ERPNext’s helper function.

Accounts Used:

Account	Account Type	Party Type	Party	Debit	Credit
Debtors – TC	Receivable	Customer	Customer A	0	2,500
Debtors – TC	Receivable	Customer	Customer B	0	3,200
Bad Debts Written Off	Expense	–	–	5,700	0

Step-by-Step Entry:

1. Navigate to: Accounting → Journal Entry → New
2. Set Entry Type: Write Off Entry
3. Set Posting Date and Company
4. In “Write Off” section:

• Write Off Based On: Accounts Receivable
• Write Off Amount: 5000 (to show only invoices ≤ ₹5,000)

1. Click Get Outstanding Invoices button
2. System auto-populates accounts table with:

• Multiple rows with customer outstanding amounts (Credit)
• Each row links to original Sales Invoice

1. Manually add balancing entry:

• Account: Bad Debts Written Off (Expense account)
• Debit: Total of all credits (5,700)
• Cost Center: Main – TC

1. Verify Total Debit = Total Credit
2. Save and Submit

GL Entry Result:

• Customer accounts are credited (reducing receivables)
• Bad Debts Written Off account is debited (expense recognized)
• Outstanding amounts on Sales Invoices become zero

---

10. OPENING ENTRY

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Opening Entry is specifically designed to record opening balances when migrating from another accounting system or starting a new financial year. 7

Business Situations Where ERPNext Expects This Type:

• Initial setup of ERPNext when migrating from legacy accounting software
• Recording opening balances for all accounts at fiscal year start
• Setting up opening customer/supplier balances
• Recording opening inventory values (for periodic inventory companies)

What ERPNext Treats Differently:
Opening Entry has special treatment throughout the accounting system – it’s handled differently in reports, GL entries, and period closing procedures.

System Behavior Triggered by This Entry Type

Critical System Behavior:
When voucher_type is set to “Opening Entry”, ERPNext automatically sets: 8

self.is_opening = "Yes"

This is_opening flag triggers cascading effects:

In GL Entry Creation:

• Uses special round-off account (round_off_for_opening) instead of standard round-off account
• Opening entries are validated against Period Closing Vouchers 9

In Financial Reports:
Opening entries receive special handling: 9

• Trial Balance: Includes entries with is_opening='Yes' in opening balance calculation
• General Ledger: Has filter to show/hide opening entries
• Financial Statements: Can exclude opening entries via ignore_opening_entries parameter

Form Behavior:
The is_opening field becomes “Yes” automatically and is read-only once set.

Real-Life ERPNext Example (End-to-End)

Scenario: Company migrates to ERPNext on 1st April 2024. Previous system shows closing balances on 31st March 2024 that need to be recorded as opening balances.

Why Opening Entry is Chosen:
These are not regular transactions but migration entries that should be tagged as opening balances for proper financial reporting.

Accounts Used (Sample):

Account	Account Type	Party Type	Party	Debit	Credit
HDFC Bank	Bank	–	–	500,000	0
Petty Cash	Cash	–	–	25,000	0
Fixed Assets	Fixed Asset	–	–	2,000,000	0
Debtors	Receivable	Customer	Customer A	150,000	0
Debtors	Receivable	Customer	Customer B	75,000	0
Creditors	Payable	Supplier	Supplier X	0	180,000
Share Capital	Equity	–	–	0	1,500,000
Retained Earnings	Equity	–	–	0	1,070,000

Step-by-Step Entry:

1. Navigate to: Accounting → Journal Entry → New
2. Set Entry Type: Opening Entry
3. Set Posting Date: 1st April 2024 (fiscal year start date)
4. Set Company: Your Company
5. Notice Is Opening automatically becomes “Yes” (cannot be changed)
6. In Accounts table, add all accounts with opening balances:

• Add all Asset accounts as Debit entries
• Add all Liability and Equity accounts as Credit entries
• For Receivable/Payable accounts, specify:
  • Party Type: Customer/Supplier
  • Party: Specific party name

1. Ensure Total Debit = Total Credit (balance sheet equation)
2. Add User Remark: “Opening Balances as on 31-Mar-2024”
3. Save and Submit

Important Considerations:

• Opening entries should be dated at the start of the fiscal year
• They must balance (Total Debit = Total Credit)
• Party-wise opening balances require Party Type and Party specification
• Reports will treat these entries differently than regular transactions

---

11. DEPRECIATION ENTRY

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Depreciation Entry is specifically designed for automatic depreciation booking from the Asset module. It ensures depreciation is recorded in the correct expense accounts with proper asset references. 10

Business Situations Where ERPNext Expects This Type:

• Monthly/Quarterly/Yearly automatic depreciation booking
• Manual depreciation entry booking
• Depreciation catch-up entries
• Pro-rata depreciation at asset disposal time

What ERPNext Treats Differently:
Depreciation Entry has strict validations that other entry types don’t have. It also integrates tightly with the Asset module to update asset values.

System Behavior Triggered by This Entry Type

Critical Validation:
ERPNext enforces strict validation on Depreciation Entry: 10

Validation Rules:

1. If any account has account_type = "Depreciation", then voucher_type MUST be “Depreciation Entry”
2. The depreciation account must have root_type = "Expense"
3. Prevents misuse of depreciation accounts in other journal entry types

Asset Value Updates:
On submission, update_asset_on_depreciation() method: 11

1. Identifies asset reference in journal entry accounts
2. Updates value_after_depreciation on Asset
3. Links journal entry to Asset Depreciation Schedule
4. Sets asset status appropriately
5. Updates total booked depreciations

Reference Requirement:
Each depreciation entry row should have:

• Reference Type: Asset
• Reference Name: Specific asset being depreciated

Real-Life ERPNext Example (End-to-End)

Scenario: Company books monthly depreciation of ₹10,000 on “Dell Laptop – LAPTOP001” purchased for ₹1,20,000 with 10-year useful life (straight-line depreciation).

Why Depreciation Entry is Chosen:
This is asset depreciation which requires special Asset module integration and must use Depreciation Entry type per ERPNext validation rules.

Accounts Used:

Account	Account Type	Reference Type	Reference Name	Debit	Credit
Depreciation – Computers	Depreciation (Expense)	Asset	LAPTOP001	10,000	0
Accumulated Depreciation – Computers	Accumulated Depreciation	Asset	LAPTOP001	0	10,000

Step-by-Step Entry:

1. Automatic Creation (Preferred Method):

• Navigate to: Assets → Asset → LAPTOP001
• In “Depreciation Schedule” section, click “Make Depreciation Entry” button for due date
• System auto-creates Journal Entry with voucher_type = “Depreciation Entry”
• Pre-populates all fields including asset references
• Review and Submit

1. Manual Creation (If needed):

• Navigate to: Accounting → Journal Entry → New
• Set Entry Type: Depreciation Entry
• Set Posting Date: Month end date
• Set Company: Your Company
• First row in accounts table:
  • Account: Depreciation – Computers (must be Expense type)
  • Debit: 10,000
  • Cost Center: Main – TC
  • Reference Type: Asset
  • Reference Name: LAPTOP001
• Second row:
  • Account: Accumulated Depreciation – Computers
  • Credit: 10,000
  • Cost Center: Main – TC
  • Reference Type: Asset
  • Reference Name: LAPTOP001
• Save and Submit

System Actions on Submission:

1. GL entries created (Debit: Depreciation Expense, Credit: Accumulated Depreciation)
2. Asset’s value_after_depreciation reduced by ₹10,000
3. Journal Entry linked to Asset Depreciation Schedule
4. Asset status updated if fully depreciated

Validation Errors to Avoid:

• Using “Depreciation Entry” without a Depreciation-type account → Not enforced but illogical
• Using Depreciation-type account with non-Depreciation Entry type → System throws error
• Missing asset reference → Entry succeeds but asset not updated

---

12. ASSET DISPOSAL

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Asset Disposal entry type is designed to handle the accounting treatment when an asset is scrapped, sold, or otherwise disposed of, including recording gain/loss on disposal. 12

Business Situations Where ERPNext Expects This Type:

• Asset scrapping (zero or nominal salvage value)
• Asset sale through Sales Invoice with accounting adjustments
• Asset disposal due to damage/obsolescence
• Asset retirement at end of useful life

What ERPNext Treats Differently:
Asset Disposal entries automatically update the Asset master with disposal information and trigger asset status changes.

System Behavior Triggered by This Entry Type

Automatic Asset Updates:
When voucher_type = "Asset Disposal", the update_asset_on_disposal() method: 12

1. Sets disposal_date = posting_date on the Asset
2. Links journal_entry_for_scrap field to this journal entry
3. Updates asset status to “Disposed”/”Sold”/”Scrapped”
4. Prevents further depreciation entries

Reference Requirement:
Each row must have:

• Reference Type: Asset
• Reference Name: Asset being disposed

Typical Accounting Structure:
For asset disposal, you need to:

1. Clear the asset’s cost (Credit: Fixed Asset Account)
2. Clear accumulated depreciation (Debit: Accumulated Depreciation)
3. Record any proceeds (Debit: Bank/Cash if sold)
4. Record gain/loss on disposal (Debit: Loss or Credit: Gain)

Real-Life ERPNext Example (End-to-End)

Scenario: Company scraps an old computer purchased for ₹80,000 with accumulated depreciation of ₹72,000. Scrap value realized is ₹5,000 cash.

Why Asset Disposal is Chosen:
This is a disposal transaction that needs to remove the asset from books, recognize gain/loss, and update the Asset master’s disposal status.

Calculation:

• Original Cost: ₹80,000
• Accumulated Depreciation: ₹72,000
• Net Book Value: ₹8,000
• Scrap Value Realized: ₹5,000
• Loss on Disposal: ₹3,000

Accounts Used:

Account	Account Type	Reference Type	Reference Name	Debit	Credit
Accumulated Depreciation – Computers	Accumulated Depreciation	Asset	COMP001	72,000	0
Cash Account	Cash	–	–	5,000	0
Loss on Asset Disposal	Expense	–	–	3,000	0
Computer Equipment	Fixed Asset	Asset	COMP001	0	80,000

Step-by-Step Entry:

1. Via Asset Form (Recommended):

• Navigate to: Assets → Asset → COMP001
• Click “Scrap Asset” button
• Enter Scrap Value: 5,000
• System auto-creates Journal Entry with voucher_type = “Asset Disposal”
• Review and Submit

1. Manual Creation:

• Navigate to: Accounting → Journal Entry → New
• Set Entry Type: Asset Disposal
• Set Posting Date: Disposal date
• Set Company: Your Company
• Add accounts: Row 1 – Clear Accumulated Depreciation:
  • Account: Accumulated Depreciation – Computers
  • Debit: 72,000
  • Reference Type: Asset
  • Reference Name: COMP001 Row 2 – Record Cash Received:
  • Account: Cash Account
  • Debit: 5,000 Row 3 – Record Loss:
  • Account: Loss on Asset Disposal
  • Debit: 3,000
  • Cost Center: Main – TC Row 4 – Remove Asset from Books:
  • Account: Computer Equipment (Fixed Asset)
  • Credit: 80,000
  • Reference Type: Asset
  • Reference Name: COMP001

1. Verify Total Debit (80,000) = Total Credit (80,000)
2. Save and Submit

System Actions on Submission:

1. GL entries created as per above
2. Asset COMP001 updated:

• disposal_date = posting_date
• journal_entry_for_scrap = this JE name
• Status = “Disposed”

1. Asset no longer appears in active asset reports
2. Future depreciation entries blocked for this asset

---

13. PERIODIC ACCOUNTING ENTRY

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Periodic Accounting Entry is designed exclusively for companies using periodic inventory (not perpetual inventory) to reconcile stock account balances with actual stock values. 13

Business Situations Where ERPNext Expects This Type:

• Month-end/quarter-end stock reconciliation in periodic inventory companies
• Adjusting stock account balances to match physical stock valuations
• Recording stock value differences due to pricing changes
• Period-end closing entries for inventory accounts

What ERPNext Treats Differently:
This entry type has special validation, dedicated helper function, and exemption from normal stock account restrictions.

System Behavior Triggered by This Entry Type

Special Validation:
When voucher_type = “Periodic Accounting Entry”: 14

1. Cannot be used in perpetual inventory companies – System throws error
2. Requires mandatory field: periodic_entry_difference_account
3. Exempted from stock account validation – Normal restriction preventing direct stock account JE is bypassed

Special UI Fields Displayed: 15

• Periodic Entry Difference Account: Mandatory account for balancing differences
• For All Stock Asset Accounts: Checkbox (default checked)
• Stock Asset Account: Conditional field if above checkbox unchecked
• Get Balance button: Triggers automatic calculation

Get Balance Button Functionality:
When clicked, get_balance_for_periodic_accounting() method: 16

1. Fetches all stock accounts (or selected stock account)
2. Calls get_stock_and_account_balance() for each account
3. Compares GL account balance vs. Stock Ledger balance
4. Auto-populates accounts table with:

• Stock account (debit if stock > account, credit if stock < account)
• Difference account (opposite entry to balance)

1. Shows message if no difference found

Real-Life ERPNext Example (End-to-End)

Scenario: Periodic inventory company conducts month-end stock valuation on 31-Jan-2024. Stock account shows ₹5,00,000 in GL, but actual stock value per Stock Ledger is ₹5,15,000.

Why Periodic Accounting Entry is Chosen:
This is a stock-to-account reconciliation that requires:

• Direct posting to stock accounts (normally restricted)
• System-assisted calculation of differences
• Period-end adjustment treatment

Calculation:

• GL Account Balance (Stock in Hand): ₹5,00,000
• Stock Ledger Balance: ₹5,15,000
• Difference: ₹15,000 (Stock is undervalued in accounts)
• Action: Debit Stock Account, Credit Difference Account

Accounts Used:

Account	Account Type	Debit	Credit
Stock in Hand	Stock (Asset)	15,000	0
Stock Adjustment	Expense	0	15,000

Step-by-Step Entry:

1. Prerequisite Check:

• Navigate to: Setup → Company → Your Company
• Verify “Enable Perpetual Inventory” is UNCHECKED
• If checked, Periodic Accounting Entry cannot be used

1. Create Entry:

• Navigate to: Accounting → Journal Entry → New
• Set Entry Type: Periodic Accounting Entry
• Set Posting Date: 31-Jan-2024 (period end)
• Set Company: Your Company

1. Configure Periodic Accounting Section:

• Periodic Entry Difference Account: Stock Adjustment (mandatory)
• For All Stock Asset Accounts: Leave checked (or uncheck to select specific account)
• If unchecked, select Stock Asset Account: Stock in Hand

1. Auto-Calculate:

• Click Get Balance button
• System queries stock vs. account balance
• Auto-populates accounts table:
  • Row 1: Stock in Hand – Debit: 15,000
  • Row 2: Stock Adjustment – Credit: 15,000

1. Review:

• Verify Total Debit = Total Credit
• Check all stock accounts are covered
• Add User Remark: “Month-end stock reconciliation for Jan 2024”

1. Save and Submit

System Actions:

1. GL entries created adjusting stock account
2. Stock account balance now matches Stock Ledger
3. Difference posted to expense account
4. Entry bypasses normal stock account posting restriction

Important Notes:

• Only use in periodic inventory companies
• Run at regular intervals (monthly/quarterly)
• Difference account shows stock gain/loss due to valuation changes
• Cannot be used with perpetual inventory enabled

---

14. EXCHANGE RATE REVALUATION

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Exchange Rate Revaluation is automatically created by the Exchange Rate Revaluation DocType to book unrealized foreign exchange gains and losses on foreign currency account balances. 1

Business Situations Where ERPNext Expects This Type:

• Period-end revaluation of foreign currency bank accounts
• Quarter-end/year-end foreign currency asset/liability revaluation
• Compliance with accounting standards (IFRS, GAAP) requiring mark-to-market
• Monthly unrealized forex gain/loss booking

What ERPNext Treats Differently:
This entry type is typically system-generated from the Exchange Rate Revaluation module and records adjustments to reflect current exchange rates on foreign currency balances.

System Behavior Triggered by This Entry Type

System Generation:
Exchange Rate Revaluation entries are created by: 1

• Exchange Rate Revaluation DocType
• Auto-scheduled revaluation (if configured in Company)
• Manual revaluation runs

Typical Structure:

• One side: Foreign currency account (adjustment to reflect new rate)
• Other side: Unrealized Exchange Gain/Loss account (configured in Company)
• Multi-currency is enabled
• System-generated flag is set

Form Behavior:
Standard journal entry form with multi-currency fields visible.

Real-Life ERPNext Example (End-to-End)

Scenario: Company has USD bank account with balance of $10,000. At month-end:

• Original exchange rate: ₹75 per USD (Book value: ₹7,50,000)
• Current exchange rate: ₹77 per USD (Current value: ₹7,70,000)
• Unrealized gain: ₹20,000

Why Exchange Rate Revaluation is Chosen:
To comply with accounting standards requiring foreign currency assets to be revalued at current exchange rates at period-end.

Accounts Used:

Account	Account Currency	Debit (INR)	Credit (INR)	Debit (Currency)	Credit (Currency)
HDFC Bank USD	USD	20,000	0	0	0
Unrealized Exchange Gain/Loss	INR	0	20,000	0	20,000

Step-by-Step Entry:

1. Automatic Creation (Recommended):

• Navigate to: Accounting → Exchange Rate Revaluation → New
• Set Company: Your Company
• Set Posting Date: Month-end date
• Click Get Entries button
• System fetches all foreign currency accounts
• For each account, shows:
  • Current balance in foreign currency
  • Balance in company currency at original rate
  • Balance in company currency at current rate
  • Gain/Loss amount
• Review differences
• Click Create Journal Entry button
• System creates Journal Entry with voucher_type = “Exchange Rate Revaluation”
• Review and Submit

1. Manual Creation (Not Recommended):

• Navigate to: Accounting → Journal Entry → New
• Set Entry Type: Exchange Rate Revaluation
• Set Multi Currency: Checked
• Set Posting Date: Month-end
• Add accounts: Row 1:
  • Account: HDFC Bank USD
  • Debit: 20,000 (in INR)
  • Account Currency: USD
  • Exchange Rate: 77 (current rate) Row 2:
  • Account: Unrealized Exchange Gain/Loss
  • Credit: 20,000
  • Exchange Rate: 1

1. Save and Submit

Reversal at Next Period:
Next month-end, this entry is typically reversed and a new revaluation entry created reflecting the new exchange rate, ensuring only net unrealized gain/loss is shown.

---

15. EXCHANGE GAIN OR LOSS

Purpose of This Entry Type in ERPNext

Why This Entry Type Exists:
Exchange Gain Or Loss entries are automatically created by ERPNext when payments or journal entries are reconciled against invoices at exchange rates different from the invoice rate. 17

Business Situations Where ERPNext Expects This Type:

• Payment received against foreign currency sales invoice at different exchange rate
• Payment made against foreign currency purchase invoice at different exchange rate
• Journal entry reconciliation with rate differences
• Settlement of foreign currency invoices with forex variance

What ERPNext Treats Differently:
This is a system-generated entry type with special privileges:

• Exempt from total debit = total credit validation in multi-currency scenarios
• Auto-created during payment/invoice reconciliation
• Marked as is_system_generated = True

System Behavior Triggered by This Entry Type

Special Validation Exemption:
Exchange Gain Or Loss entries are exempt from normal validations: 18

1. Can have debit ≠ credit in multi-currency scenarios
2. Can have zero debit and credit in individual rows
3. System automatically calculates and posts forex variance

Automatic Creation Process:
When payment is made/received at different rate than invoice: 17

1. System detects exchange rate difference
2. Calls make_exchange_gain_loss_journal() method
3. Creates journal entry automatically
4. Posts to Exchange Gain/Loss account configured in Company

Form Behavior:

• Multi-currency must be enabled
• System-generated checkbox is marked
• Users typically cannot create this manually

Real-Life ERPNext Example (End-to-End)

Scenario:

• Sales Invoice SI-001 raised to US customer for $1,000 when rate was ₹75/USD = ₹75,000
• Payment received 30 days later when rate is ₹77/USD = ₹77,000
• Realized gain: ₹2,000

Why Exchange Gain Or Loss is Chosen:
System automatically chooses this type to record the realized forex gain that occurred between invoice and payment dates.

Original Invoice GL Entry:

Account	Debit (INR)	Credit (INR)
Debtors USD	75,000	0
Sales	0	75,000

Payment Entry GL (simplified):

Account	Debit (INR)	Credit (INR)
Bank	77,000	0
Debtors USD	0	75,000

System-Generated Exchange Gain/Loss Entry:

Account	Debit (INR)	Credit (INR)
Debtors USD	0	2,000
Exchange Gain/Loss	2,000	0

Process Flow (Automatic):

1. User creates and submits Payment Entry:

• Party Type: Customer
• Party: US Customer
• Paid Amount: $1,000
• Received Amount: ₹77,000
• Exchange Rate: 77
• References tab: Select Invoice SI-001

1. User clicks Get Outstanding Invoices:

• System fetches SI-001 with outstanding $1,000
• Original rate: 75
• Current rate: 77
• System detects rate difference

1. On Payment Entry Submission:

• System creates Payment Entry GL entries
• Automatically creates Journal Entry:
  • Entry Type: Exchange Gain Or Loss
  • Is System Generated: Yes
  • Multi Currency: Yes
  • Adjusts debtor account for forex variance
  • Books gain to Exchange Gain/Loss account
• Links this JE to payment entry

1. User Verifies (after submission):

• Navigate to: Accounts → Journal Entry → Filter: “Exchange Gain Or Loss”
• Find auto-created entry
• Review GL entries
• Entry shows zero outstanding on invoice

Accounts Used (Auto-generated):

Account	Account Type	Debit	Credit	Party Type	Party
Debtors USD	Receivable	0	2,000	Customer	US Customer
Exchange Gain/Loss	Income/Expense	2,000	0	–	–

Important Notes:

• Users typically don’t create this entry type manually
• System creates it automatically during payment reconciliation
• If forex loss (rate decreased), debit/credit are reversed
• This records realized forex gain/loss (vs. unrealized in revaluation)

---

16- Deferred Revenue

Deferred Revenue is used when you receive payment for services that will be delivered over time. The revenue is initially recorded in a liability account (Deferred Revenue) and then gradually recognized as actual income over the service period.

System Behavior When Deferred Revenue is Enabled

When you enable deferred revenue on a Sales Invoice item, the system changes its accounting behavior:

1. Initial GL Entry: Instead of crediting the income account directly, the system credits the deferred_revenue_account when the invoice is submitted. 1
2. Required Fields: The system requires specific fields on each deferred revenue item:

• enable_deferred_revenue (checkbox)
• deferred_revenue_account (liability account)
• service_start_date and service_end_date (defines the service period) 2

1. Validation: The system validates that a deferred revenue account is set and service dates are valid. 3 4

How Deferred Revenue Items are Referenced from Sales Invoices

Sales Invoice items can be configured for deferred revenue in two ways:

1. Item Master Configuration: Items can have deferred revenue enabled by default with enable_deferred_revenue, deferred_revenue_account, and no_of_months fields set on the Item. 5
2. Invoice-Level Configuration: When adding an item to a Sales Invoice, you can manually enable deferred revenue and set the service dates for that specific transaction.

Automatic Journal Entry Creation Process

The Process Deferred Accounting module is responsible for converting deferred revenue into actual income over time:

1. Creating a Process Deferred Accounting Document: You create a document with:

• type: “Income” (for revenue) or “Expense” (for expenses)
• start_date and end_date: The period to process
• company: The company to process for
• Optional: specific account to filter 6

1. On Submission: The system calls convert_deferred_revenue_to_income() which queries all Sales Invoices with deferred revenue items that fall within the processing period. 7
2. Journal Entry Creation Mode: Based on the book_deferred_entries_via_journal_entry setting in Accounts Settings, the system either:

• Creates Journal Entries with voucher_type “Deferred Revenue”
• Creates direct GL Entries 8

1. Journal Entry Structure: When booking via journal entries, the system creates entries with:

• Debit: Income Account (recognizing revenue)
• Credit: Deferred Revenue Account (reducing liability)
• Links back to the original Sales Invoice via reference_name and reference_detail_no 9

Step-by-Step Revenue Recognition Process

1. Calculate Booking Dates: The system determines which period to recognize revenue for, checking for previous GL entries to avoid double-booking. 10
2. Calculate Amount: Based on the book_deferred_entries_based_on setting (Days or Months), the system calculates the amount to recognize:

• Days Method: Prorates revenue based on actual days in the period
• Months Method: Books fixed monthly amounts, prorated for partial months 11 12 13

1. Book Entries: The system creates GL entries or Journal Entries to transfer the amount from deferred revenue account to income account. 14
2. Recursive Processing: If the end date is before the posting date and not the last entry, the system recursively processes the next period. 15
3. Handle Frozen Periods: If accounts are frozen, the system adjusts the posting date to the first available date after the frozen period. 16

17- Deferred Expense

Deferred Expense works similarly but in the opposite direction – it’s used when you pay for services upfront that will be consumed over time (e.g., annual insurance, prepaid rent).

Purpose and System Behavior

1. Initial Recording: When a Purchase Invoice with deferred expense items is submitted, the expense is debited to a deferred_expense_account (asset account) instead of the expense account.
2. Required Fields: Purchase Invoice items need:

• enable_deferred_expense
• deferred_expense_account (asset account)
• service_start_date and service_end_date 17

1. Processing: The Process Deferred Accounting document with type="Expense" calls convert_deferred_expense_to_expense() to gradually recognize the expense. 18

Real-World Usage Examples

Example 1: Deferred Revenue (Subscription Service)

A company sells an annual software subscription for $1,200 on January 10, 2019, with service from January 10 to March 15, 2019: 19

In this example:

• Initial invoice credits $1,200 to Deferred Revenue (liability)
• Process Deferred Accounting runs monthly
• January: Recognizes $33.85 (21 days prorated)
• February: Recognizes $43.08 (28 days)
• March: Recognizes $23.07 (15 days until service ends)

Example 2: Deferred Expense (Prepaid Services)

A company pays $100 for a service covering January 10 to March 15, 2019: 20

The expense is gradually recognized:

• Initial invoice debits $100 to Deferred Expense (asset)
• January: Recognizes $33.85 expense
• February: Recognizes $43.08 expense
• March: Recognizes $23.07 expense (until service period ends)

Example 3: Monthly-Based Booking

With the “Months” booking method, a $50,000 subscription from January 16 to March 31 is recognized as:

• January: $10,000 (prorated partial month)
• February: $20,000 (full month)
• March: $20,000 (full month) 21

Automatic Processing

The system can automatically process deferred accounting entries via scheduled jobs when the automatically_process_deferred_accounting_entry setting is enabled: 22