Accounts Payable and Receivable

Overview

• What you’ll learn:
  • How the Accounts Payable cycle works in iDempiere — from purchase order through vendor invoice to payment
  • How the Accounts Receivable cycle works — from sales order through customer invoice to receipt of payment
  • How to manage payments, allocations, aging, dunning, credit memos, and bank statement reconciliation
• Prerequisites: Lesson 26 — Chart of Accounts and General Ledger Setup (understanding of account defaults and posting logic)
• Estimated reading time: 25 minutes

Introduction

Accounts Payable (AP) and Accounts Receivable (AR) are the two sides of the same coin — AP tracks what you owe to your vendors, and AR tracks what your customers owe to you. Together, they form the transactional heartbeat of the financial module, generating the majority of journal entries and directly affecting cash flow.

In iDempiere, AP and AR are not isolated modules. They are deeply integrated with purchasing, sales, inventory, and the general ledger. A vendor invoice does not exist in isolation — it is linked to a purchase order and a material receipt, enabling three-way matching. A customer payment does not just reduce a bank balance — it is allocated against specific invoices, clearing the receivable and updating the aging report.

This lesson follows the complete invoice-to-payment cycle for both vendors (AP) and customers (AR).

The Accounts Payable Cycle

The AP cycle in iDempiere follows this flow:

Purchase Order → Material Receipt → Vendor Invoice → Payment

Each step in this cycle generates accounting entries that progressively record the financial impact of the transaction.

Step 1: Purchase Order

The purchase order (PO) represents a commitment to buy goods or services from a vendor. In standard accrual accounting, a PO does not generate a GL entry by default (the obligation is contingent on delivery). However, if commitment accounting (encumbrance) is enabled on the Accounting Schema, completing a PO generates:

This commitment entry is reversed when the material receipt or invoice is posted.

Step 2: Material Receipt

When goods arrive and a Material Receipt (MR) is completed, inventory is increased and a liability accrual is created:

The “Not Invoiced Receipts” account is a temporary liability — it acknowledges that goods have been received but the vendor invoice has not yet arrived. This is the accrual principle in action.

Step 3: Vendor Invoice

When the vendor invoice arrives, it is entered in iDempiere and matched to the material receipt. Completing the invoice generates:

If there are tax amounts, additional entries debit Tax Credit and credit Accounts Payable for the tax portion. At this point, the liability has moved from the temporary accrual account to the proper AP account.

Step 4: Payment

When you pay the vendor, completing the payment generates:

The AP balance is cleared and the bank balance is reduced. The payment must then be allocated to the specific invoice(s) it covers — this is described in the Allocation section below.

The Accounts Receivable Cycle

The AR cycle mirrors the AP cycle from the seller’s perspective:

Sales Order → Shipment → Customer Invoice → Receipt (Payment)

Step 1: Sales Order

The sales order records a customer’s intent to purchase. Like purchase orders, standard sales orders do not generate GL entries unless commitment accounting is enabled.

Step 2: Shipment

When goods are shipped (Material Shipment completed), inventory is reduced and cost of goods sold is recognized:

Note that revenue is not recognized at shipment — it is recognized at invoicing, following the revenue recognition principle.

Step 3: Customer Invoice

Completing the customer invoice recognizes revenue and creates the receivable:

Step 4: Receipt (Customer Payment)

When the customer pays, the receipt clears the receivable:

The C_Invoice Table

Both vendor invoices and customer invoices are stored in the C_Invoice table, distinguished by the IsSOTrx flag (Sales Transaction). The table has a header-lines structure:

Invoice Header (C_Invoice)

Key fields:

• DocumentNo: Unique invoice number
• C_BPartner_ID: The vendor or customer
• DateInvoiced: The invoice date
• DateAcct: The accounting date (determines which period the posting falls in)
• C_DocTypeTarget_ID: Document type — AP Invoice, AP Credit Memo, AR Invoice, AR Credit Memo
• C_PaymentTerm_ID: Payment terms (Net 30, 2/10 Net 30, etc.)
• IsSOTrx: Y for customer invoices (AR), N for vendor invoices (AP)
• GrandTotal: Total invoice amount including tax
• IsPaid: Whether the invoice has been fully allocated/paid
• C_Order_ID: Link to the originating purchase order or sales order

Invoice Lines (C_InvoiceLine)

Each line represents an item being invoiced:

• M_Product_ID / C_Charge_ID: The product or charge being invoiced
• QtyInvoiced: Quantity
• PriceActual: Unit price after discounts
• LineNetAmt: Line total (quantity x price)
• C_Tax_ID: Applicable tax rate
• M_InOutLine_ID: Link to the material receipt/shipment line for matching
• C_OrderLine_ID: Link to the purchase/sales order line for matching

Invoice Matching — Three-Way Match

Three-way matching is a critical internal control in accounts payable. It compares three documents to ensure consistency before approving a vendor invoice for payment:

1. Purchase Order: What was ordered (product, quantity, price)
2. Material Receipt: What was received (product, quantity)
3. Vendor Invoice: What the vendor is billing (product, quantity, price)

In iDempiere, matching occurs through the link fields on the invoice line: C_OrderLine_ID connects to the PO line, and M_InOutLine_ID connects to the receipt line. The Matching PO and Matching Invoice windows (under Material Management) allow you to review and create matches.

The system can identify discrepancies:

• Quantity variance: Invoice quantity differs from receipt quantity
• Price variance: Invoice price differs from PO price — generates a Price Difference posting to a variance account
• Unmatched invoices: Invoices without corresponding receipts or POs, flagged for review

The C_Payment Table

Payments in iDempiere are stored in the C_Payment table. Like invoices, both incoming (customer) and outgoing (vendor) payments use the same table, distinguished by the IsReceipt flag.

Key fields:

• DocumentNo: Payment reference number
• C_BPartner_ID: The business partner
• IsReceipt: Y for customer payments (money in), N for vendor payments (money out)
• C_BankAccount_ID: The bank account used
• PayAmt: The payment amount
• TenderType: The payment method
• DateTrx: Transaction date
• DateAcct: Accounting date
• C_Invoice_ID: Optionally, a direct link to a single invoice (for simple 1:1 payments)
• IsAllocated: Whether this payment has been fully matched to invoices

Payment Methods (Tender Types)

iDempiere supports several payment methods:

• Check (K): Payment by bank check — the system can track check numbers
• Direct Deposit / Wire Transfer (A): Electronic bank transfer
• Credit Card (C): Credit card payment — stores card type and authorization info
• Cash (X): Cash transaction — uses the Cash Journal for cash management
• Direct Debit (D): Automatic bank withdrawal authorized by the payer

Payment Allocation

Allocation is the process of matching payments to invoices. This is essential because a single payment might cover multiple invoices, or a single invoice might be paid in installments across multiple payments.

Allocation Tables

Allocations are stored in two tables:

• C_AllocationHdr: The allocation header, containing the allocation date and total amounts
• C_AllocationLine: Individual allocation lines, each connecting an invoice to a payment (or other credit document)

Key fields on C_AllocationLine:

• C_Invoice_ID: The invoice being paid
• C_Payment_ID: The payment covering the invoice
• Amount: The amount being applied from this payment to this invoice
• DiscountAmt: Early payment discount amount (if payment terms offer a discount)
• WriteOffAmt: Amount written off (for small differences deemed not worth collecting)
• OverUnderAmt: Over-payment or under-payment amount

How Allocation Works

When you allocate a payment to an invoice, the system:

1. Creates an C_AllocationHdr and C_AllocationLine record linking the payment and invoice
2. Updates the invoice’s open amount (reduces what is still owed)
3. Marks the invoice as Paid (IsPaid = Y) when the open amount reaches zero
4. Marks the payment as Allocated (IsAllocated = Y) when the full payment amount has been matched
5. Generates accounting entries to clear the AR or AP account

The Payment Allocation window provides an interactive interface where you select a business partner, see their open invoices and unallocated payments side by side, and create allocations by matching them.

Allocation Scenarios

• 1:1 Match: One payment covers exactly one invoice — the simplest case
• 1:N Match: One payment covers multiple invoices — common when a customer sends a single check for several invoices
• N:1 Match: Multiple payments cover one invoice — occurs with installment payments
• Cross-allocation: Invoices and credit memos can be allocated against each other, with or without a payment

Payment Terms and Due Dates

Payment terms (C_PaymentTerm) define when invoices are due and whether early payment discounts apply. Common payment terms include:

• Immediate: Due upon receipt of invoice
• Net 30: Due within 30 days of invoice date
• Net 60: Due within 60 days
• 2/10 Net 30: 2% discount if paid within 10 days, otherwise due in 30 days
• Net 30 End of Month: Due 30 days after the end of the invoice month

Payment terms are assigned to invoices (and default from the business partner record). The system calculates the due date automatically and uses it for aging reports and dunning.

For installment payment terms (e.g., 50% due in 30 days, 50% due in 60 days), iDempiere supports a Payment Schedule on the payment term, which splits the invoice into multiple due dates.

Aging Reports

Aging reports are the primary tool for monitoring outstanding receivables and payables. They group open invoices by how long they have been outstanding:

In iDempiere, the Aging Report (under Open Items or Performance Analysis) can be run for either AP or AR. It shows each open invoice with its business partner, invoice date, due date, open amount, and aging bucket. The report can be filtered by organization, business partner, and date range.

The aging report is invaluable for:

• Cash flow forecasting: Knowing when receivables are expected and when payables are due
• Collection prioritization: Identifying the most overdue receivables for collection action
• Vendor relationship management: Ensuring payables are paid on time to maintain good supplier relationships
• Bad debt provisioning: Identifying receivables that may need to be written off or reserved against

Cash Journals

For businesses that handle significant cash transactions, iDempiere provides a Cash Journal window. The cash journal records:

• Cash receipts from customers (walk-in payments)
• Cash disbursements (petty cash expenses)
• Cash transfers between registers or to the bank

Cash journals are associated with a Cash Book (a logical register). Each cash journal line creates appropriate accounting entries — debiting the Cash account for receipts and crediting it for disbursements. Cash journal lines can be directly allocated to invoices, functioning similarly to regular payments.

Write-Offs

A write-off closes an open invoice balance that is deemed uncollectable or not worth pursuing. In iDempiere, write-offs can be processed through:

• Payment Allocation: When allocating a payment to an invoice, you can specify a write-off amount in the WriteOffAmt field. The system generates a journal entry debiting the write-off (bad debt) expense account and crediting Accounts Receivable.
• GL Journal: For bulk write-offs or complex adjustments, a manual journal entry can be created.

The write-off account is defined in the business partner group’s accounting defaults or the accounting schema’s defaults. Best practice is to regularly review the aging report, identify uncollectable amounts, and process write-offs at period-end with proper management approval.

Credit Memos

A credit memo is a document that reduces the amount owed. In iDempiere, credit memos are invoices with a negative amount, using a specific document type:

• AP Credit Memo: Reduces what you owe a vendor — perhaps due to returned goods, a billing error, or a price adjustment. The posting reverses the vendor invoice entries: debit Accounts Payable, credit Inventory or Expense.
• AR Credit Memo: Reduces what a customer owes you — for returns, allowances, or billing corrections. The posting reverses the customer invoice entries: debit Revenue, credit Accounts Receivable.

Credit memos can be allocated against invoices through the Payment Allocation window, reducing the open balance without a monetary payment. This is common for return transactions — the return creates a credit memo that offsets the original invoice.

Payment Selection (Batch Payments)

For companies that process many vendor payments at once (e.g., weekly or biweekly payment runs), iDempiere provides the Payment Selection window. This workflow allows you to:

1. Create a Payment Selection: Specify the bank account and payment date
2. Select invoices to pay: The system shows all open AP invoices. You can filter by due date, business partner, discount availability, and other criteria. Select which invoices to include in this payment run.
3. Generate payments: The Payment Selection (Generate) process creates individual payment records for each vendor (or consolidated payments by vendor, depending on configuration)
4. Print checks or generate EFT files: The Payment Print/Export process produces check print output or electronic funds transfer files for your bank

Payment selection streamlines the AP process by batching many individual payments into a single controlled workflow, with proper authorization at each step.

Bank Statement Matching

Bank statement reconciliation is the process of matching bank transactions (from your bank statement) to payments recorded in iDempiere. This ensures that the bank balance in the ledger matches the actual bank balance.

The workflow in iDempiere:

1. Import the bank statement: Use the Bank Statement window to manually enter lines or import them from a bank file (OFX, CSV, MT940 formats are supported through import processes)
2. Match statement lines to payments: The Bank Statement Match process attempts to automatically match bank statement lines to existing payments in iDempiere based on amount, date, and reference number. Unmatched lines can be manually matched.
3. Create payments for unmatched lines: Bank charges, interest income, and other items that do not correspond to existing payments can generate new payment records directly from the bank statement line.
4. Complete the bank statement: When all lines are matched, completing the bank statement posts the final accounting entries and reconciles the Bank In Transit account against the Bank Asset account.

Regular bank reconciliation (at least monthly) is essential for detecting discrepancies — unauthorized transactions, missed payments, duplicate entries, or timing differences between when a payment was recorded and when the bank processed it.

Dunning (Collection Letters)

Dunning is the process of systematically contacting customers about overdue invoices. iDempiere includes a dunning module that automates this process:

Dunning Configuration

• Dunning (C_Dunning): Defines the dunning program — a set of escalation levels
• Dunning Level (C_DunningLevel): Each level defines the number of days overdue that triggers this level, the fee to charge, the interest rate to apply, and the letter template to use

A typical dunning program might have three levels:

Running the Dunning Process

1. Create Dunning Run: The process scans open AR invoices, determines which are overdue, and assigns the appropriate dunning level based on days outstanding
2. Review Dunning Run: Review the proposed dunning letters in the Dunning Run window. Remove any entries that should be excluded (e.g., invoices under dispute)
3. Print Dunning Letters: Generate and print or email the collection letters to customers

The dunning program is assigned to individual business partners, allowing different customers to have different dunning policies (you might have a more lenient program for strategic customers and a stricter one for high-risk accounts).

Practical Considerations

Period-End AP Procedures

• Review the AP aging report for accuracy
• Ensure all received goods have been invoiced (review the Not Invoiced Receipts account balance)
• Process any outstanding credit memos for returns
• Reconcile the AP subledger (sum of open invoices) to the GL AP account balance
• Complete the bank reconciliation for all bank accounts

Period-End AR Procedures

• Review the AR aging report and escalate overdue items
• Process write-offs for uncollectable amounts with proper approvals
• Review unapplied customer payments and allocate them
• Reconcile the AR subledger to the GL AR account balance
• Review the bad debt reserve and adjust if needed
• Run the dunning process and send collection letters

Subledger to GL Reconciliation

The AP and AR accounts in the General Ledger should always match the sum of open items in the AP/AR subledgers. If they do not match, common causes include:

• Manual GL journal entries posted directly to the AR/AP control account (this should be avoided — use document-controlled accounts)
• Unposted documents (completed but not yet posted to the GL)
• Allocation issues (payments allocated to wrong invoices or periods)
• Period boundary timing differences

Running the Accounting Fact Reconciliation report or comparing the aging report total to the GL Trial Balance can help identify and resolve these discrepancies.

Summary

Accounts Payable and Accounts Receivable in iDempiere provide a complete invoice-to-payment lifecycle for both vendors and customers. The AP cycle runs from purchase order through material receipt and vendor invoice to payment, with three-way matching ensuring accuracy. The AR cycle runs from sales order through shipment and customer invoice to receipt of payment. Payments are allocated to invoices through the allocation mechanism, supporting complex matching scenarios. Aging reports monitor outstanding balances, dunning automates collection efforts, credit memos handle adjustments, and bank statement matching ensures ledger accuracy. Together with the Chart of Accounts and GL setup covered in Lesson 26, these processes form the financial management backbone of any iDempiere implementation.

採購訂單 → 收貨 → 供應商發票 → 付款

銷售訂單 → 出貨 → 客戶發票 → 收款（付款）

購買発注 → 入庫 → 仕入先請求書 → 支払い

受注 → 出荷 → 得意先請求書 → 入金（支払い）