Invoice vs Payment: The Complete ERP Accounting Architecture

📌 The Core Concept: Invoice = Obligation, Payment = Settlement

In ERP systems such as SAP, Odoo, Microsoft Dynamics, and any serious custom-built ERP, Invoice and Payment are related but they are never the same transaction. An invoice creates a financial obligation. A payment settles that obligation. Conflating the two is one of the most common design mistakes when building an ERP or POS from scratch.

A simple business transaction unfolds like this:

Customer buys goods → Sale happens → Invoice is created
→ Customer owes money → Customer pays → Payment is recorded
→ Invoice becomes paid

Sale/Order → Invoice → Receivable → Payment → Reconciliation → Invoice Paid

For a supplier, the mirror image applies: Purchase/Order → Vendor Bill → Payable → Payment → Reconciliation → Bill Paid.

🗺️ How It Works: The Entity Relationship Map

Before any workflow or flowchart makes sense, the underlying relationships have to be right. The single biggest mistake is wiring Invoice and Payment together with a direct foreign key. In a real ERP, nothing connects to a payment directly — everything passes through an allocation record, and every posted document mirrors itself into a journal entry. The map below shows the actual shape of the data for the customer/sales side (the supplier/purchase side is the exact mirror image, with Supplier, VendorBill and Accounts Payable in place of Customer, Invoice and Accounts Receivable).

🛒 Sales Flow: Order → Delivery → Invoice → Payment

Sales is the commercial side of the transaction — it answers what did we sell, to whom, and on what terms. Not every ERP needs every step; a simple POS can collapse straight to Sale → Invoice → Payment, while an enterprise flow keeps every stage distinct and auditable.

Worked example — a customer buys ৳10,000 of goods on credit:

Invoice INV-00001
Subtotal      ৳9,000
VAT           ৳1,000
---------------------
Total        ৳10,000

Journal Entry:
  DR Accounts Receivable    10,000
      CR Sales Revenue                9,000
      CR VAT Payable                  1,000

Customer pays ৳4,000 (partial):
  DR Cash                    4,000
      CR Accounts Receivable          4,000

Outstanding = 10,000 - 4,000 = 6,000  →  status: PARTIALLY PAID

Customer pays remaining ৳6,000:
  DR Cash                    6,000
      CR Accounts Receivable          6,000

Outstanding = 0  →  status: PAID

📦 Purchase Flow: PO → Receipt → Vendor Bill → Payment

The purchase side mirrors sales exactly, but from the supplier's perspective:

Because goods receipt and vendor billing can arrive at different times, mature ERPs also track Goods Received Not Invoiced (GRNI) as an accrued liability until the vendor bill lands.

Vendor Bill
Goods       ৳100,000
VAT          ৳15,000
---------------------
Total       ৳115,000

  DR Inventory / Expense    100,000
  DR Input VAT               15,000
      CR Accounts Payable            115,000

Payment 1 = ৳80,000
Payment 2 = ৳35,000
------------------------
Outstanding = 0  →  status: PAID

🏊 Activity Diagram: The Invoice-to-Cash Swimlane

A flow diagram shows what happens to the documents. An activity diagram shows who does each step and where responsibility hands off between actors — the Customer, Sales, Accounting, and Finance. Read the numbered cards left-to-right, top-to-bottom; each handoff tag is where the process crosses into the next lane.

Notice that Accounting touches the process twice — once to record the obligation (step 4) and once to record the settlement (step 7) — and that neither touch is triggered by the other directly. Each is triggered by its own upstream document (the Invoice, then the Payment), which is exactly why the two must stay independent tables joined by an allocation record, as shown in the relationship map above.

💳 Accounts Receivable & Accounts Payable

AR is money customers owe your company. AP is money your company owes suppliers. Neither is simply a flag on the invoice table — each is effectively a subledger: a running balance per business partner, derived from every invoice, credit note, and payment posted against them.

Customer A statement
Opening Balance          ৳0
+ Invoice 1          ৳100,000
+ Invoice 2           ৳50,000
- Payment             ৳80,000
-----------------------------
Closing Balance        ৳70,000

The AR subledger total must always reconcile with the AR control account in the General Ledger:

SUM(all customer balances)  =  GL "Accounts Receivable" balance
SUM(all supplier balances)  =  GL "Accounts Payable" balance

⚖️ Double-Entry Accounting Fundamentals

Every financial event must have equal total debits and credits. This single invariant is what keeps an ERP's books internally consistent no matter how many modules write to them.

Assets = Liabilities + Equity + Revenue - Expenses

"Debit = increase, credit = decrease" is a common misconception — it depends entirely on the account type, as the table above shows. A few canonical entries:

# Sale on credit
DR Accounts Receivable
    CR Sales Revenue

# Cash received against an invoice
DR Cash
    CR Accounts Receivable

# Pay a supplier
DR Accounts Payable
    CR Bank

📒 Journal Entries & the General Ledger

Every financial event should ultimately become a journal entry — the accounting truth behind the business document.

JE-2026-000001
Date: 27-Aug-2026          Reference: INV-2026-001

Account                       Debit       Credit
--------------------------------------------------
Accounts Receivable          55,000
Sales Revenue                             50,000
VAT Payable                                5,000
--------------------------------------------------
TOTAL                        55,000       55,000

A clean schema separates the journal entry header from its lines, because one entry always has two or more balanced lines:

journal_entry
--------------------------
id
date
reference
source_type      -- e.g. "invoice", "payment", "credit_note"
source_id
description
status
posted_at

journal_entry_line
--------------------------
id
journal_entry_id  (FK)
account_id         (FK -> chart of accounts)
debit
credit
partner_id
currency
exchange_rate

The General Ledger is simply the aggregation of every posted journal entry line, grouped by account:

Business Document (Invoice / Payment / Bill)
        ↓
Accounting Event
        ↓
Journal Entry (balanced: total debit = total credit)
        ↓
General Ledger

🔗 Payment Allocation: Many-to-Many by Design

This is the concept most custom ERPs get wrong first. Don't model invoice.payment_id as a one-to-one link — in reality, one invoice can be settled by many payments, and one payment can settle many invoices.

Invoice INV-001                    Payment PAY-1001
Total = ৳100,000                   Amount = ৳100,000
                                           │
├── Payment 1 = ৳30,000                    ├── Invoice A → ৳40,000
├── Payment 2 = ৳20,000                    ├── Invoice B → ৳35,000
└── Payment 3 = ৳50,000                    └── Invoice C → ৳25,000

Total Paid = ৳100,000               (Payment applied across 3 invoices)
Balance = ৳0

The relationship Invoice ←→ Payment is therefore many-to-many, resolved through an allocation table:

payment
----------------
id
customer_id
payment_date
amount
payment_method
bank_account_id
reference
status

payment_allocation
------------------
id
payment_id     (FK)
invoice_id     (FK)
allocated_amount
allocation_date

If a payment isn't fully allocated — say a customer pays ৳100,000 against ৳90,000 of open invoices — the remaining ৳10,000 becomes an on-account credit balance rather than being force-fit onto an invoice it doesn't belong to.

🧮 Reconciliation

Allocation and reconciliation are related but distinct. Allocation answers how much of this payment applies to this invoice? Reconciliation answers which AR journal entries offset each other?

Invoice Journal Entry:   AR  +100,000
Payment Journal Entry:   AR  -100,000
                              ────────
Reconciled AR balance:          0     →  Invoice = PAID

Partial reconciliation works the same way, just leaving a remainder:

AR Debit  (invoice)     100,000
AR Credit (payment)      40,000
-------------------------------
Remaining outstanding    60,000   →  status: PARTIALLY PAID

🔄 Invoice & Payment Lifecycle

A professional ERP derives status from a controlled state machine rather than letting any code path set status freely.

Invoice lifecycle                    Payment lifecycle

DRAFT                                 Created
  ↓                                     ↓
CONFIRMED                             Pending
  ↓                                     ↓
POSTED  ──► JOURNAL ENTRY             Posted
  ↓                                     ↓
OUTSTANDING                           Allocated
  ↓ (payment received)                  ↓
PARTIALLY PAID                        Reconciled
  ↓ (fully allocated)
PAID

The outstanding balance is always derived, never stored as a naive flag:

Outstanding Balance =
      Invoice Total
    - Credit Notes
    - Allocated Payments
    + Debit Adjustments

Outstanding = 0  →  PAID

🎛️ The Multi-Dimensional Status Model

A common mistake is cramming everything into one invoice.status field. In practice an invoice has four independent dimensions — whether the document itself is finalized, how much of it is settled, whether it's overdue, and (separately) where the payment that's settling it stands. Mixing them together produces states like "overdue_partial_cancelled" that are impossible to query cleanly.

🔀 Flowchart: The Settlement Decision Logic

This is the actual decision tree an ERP runs every time a payment is recorded against an invoice — the logic behind the lifecycle and the status model above, made explicit.

🧾 Credit Notes, Refunds, Overpayments & Advances

Credit note

Never edit a posted invoice to reflect a return. Issue a credit note instead, preserving the audit trail:

Original Invoice       ৳100,000
Credit Note              -৳20,000
----------------------------------
Net Receivable            ৳80,000

Refund

Different from a credit note — the ERP should preserve all three transactions rather than netting them away:

Invoice        ৳100,000
Paid           ৳100,000
Refund          -৳20,000
--------------------------
Net received     ৳80,000

Overpayment

Invoice  = ৳10,000
Payment  = ৳15,000

Allocation to invoice = ৳10,000  →  invoice PAID
Unallocated           =  ৳5,000  →  customer on-account credit

Advance payment

Customers can pay before an invoice even exists — the advance becomes a credit that later invoices draw down:

Advance payment          ৳50,000  →  Customer Credit
Later invoice             ৳80,000
Applied from advance     -৳50,000
--------------------------------------
Outstanding remaining     ৳30,000

🧪 Scenario Playbook: A ৳1,000 Invoice Under 40+ Conditions

The formula from the lifecycle section — Outstanding = Invoice Total − Credits/Adjustments − Allocated Payments + Debit Adjustments — has to survive every real condition a customer, cashier, or bank can throw at it. Below is a single ৳1,000 invoice run through the full range of scenarios an ERP must handle correctly. The same logic mirrors exactly onto the AP/supplier side.

1. Partial payment progression

The core case: any amount between ৳0 and ৳1,000 leaves the invoice PARTIALLY_PAID — there is no special threshold at 25%, 50%, or 90%. Only Outstanding = 0 flips it to PAID.

2. Many payments settling one invoice

There is no limit on how many payments can close one invoice — the allocation table simply accumulates rows until the sum reaches the total.

3. One payment settling many invoices

The mirror case, exercising the many-to-many allocation from the allocation section.

4. Overpayment, advances & credit balances

5. Credit notes, discounts, write-offs & tax

6. Reversals, cancellations & corrections

7. Timing, currency & operational scenarios

8. Every scenario mirrors onto Accounts Payable

Nothing above is customer-specific — replace Customer→Supplier, Invoice→Vendor Bill, and Accounts Receivable→Accounts Payable, and the exact same allocation, reconciliation, and status logic applies.

🔍 Three-Way Matching

On the purchase side, mature ERPs cross-check the Purchase Order, Goods Receipt, and Vendor Bill before releasing payment:

Purchase Order    100 units @ ৳1,000
Goods Receipt      95 units received
Vendor Bill       100 units billed
                    ─────────────────
                    Mismatch = 5 units  →  flagged for approval

The sales-side equivalent compares Ordered vs. Delivered vs. Invoiced quantities before an invoice is allowed to post.

🛡️ Audit Trail: Why You Never Delete Posted Documents

A posted invoice is referenced by AR, the General Ledger, tax reports, and customer statements. Deleting it silently breaks all of them. Enterprise systems only allow Draft → Edit, but Posted → Reverse / Cancel / Credit Note — never Posted → Delete.

audit_log
--------------------
id
user_id
action          -- CREATE, UPDATE, POST, CANCEL
entity_type     -- "invoice", "payment", ...
entity_id
timestamp
old_values      (jsonb)
new_values      (jsonb)
reason

Corrections to posted financial data should be made by reversing the original entry and posting a new one — never by rewriting history:

Original JE:  DR Expense 50,000 / CR Bank 50,000
Reversal JE:  DR Bank 50,000 / CR Expense 50,000
Corrected JE: (the accurate entry)

🗄️ Recommended Database Schema (Django/PostgreSQL)

For a Django/PostgreSQL ERP, keep Sales, Purchase, and Accounting as separate layers connected through documents and journal entries — not as tightly-coupled tables reaching into each other's internals.

Customer ──┬── Sales Order ── Order Lines
           │
           └── Invoice ── Invoice Lines
                  │
                  ↓
          Accounts Receivable
                  │
                  ↓
          Payment Allocation ←── Payment
                  │
                  ↓
            Journal Entry ── Journal Entry Lines
                  │
                  ↓
              GL Accounts

Supplier ──┬── Purchase Order ── PO Lines
           │
           └── Vendor Bill ── Bill Lines
                  │
                  ↓
           Accounts Payable
                  │
                  ↓
          Payment Allocation ←── Supplier Payment
                  │
                  ↓
            Journal Entry ── Journal Entry Lines
                  │
                  ↓
              GL Accounts

Core entities worth modeling explicitly:

Customer, Supplier
ChartOfAccount, Account

SalesOrder, SalesOrderLine
Delivery, DeliveryLine
Invoice, InvoiceLine

PurchaseOrder, PurchaseOrderLine
GoodsReceipt, GoodsReceiptLine
VendorBill, VendorBillLine

Payment, PaymentAllocation
CreditNote, CreditNoteLine, DebitNote

JournalEntry, JournalEntryLine
Reconciliation, ReconciliationLine

CashAccount, BankAccount
Tax, TaxRate, Currency, ExchangeRate
AuditLog, DocumentSequence

📊 Chart of Accounts & Control Accounts

Double-entry accounting needs a structured Chart of Accounts underneath it:

1000 Assets
├── 1100 Cash
├── 1200 Bank
├── 1300 Accounts Receivable   (control account)
└── 1400 Inventory

2000 Liabilities
├── 2100 Accounts Payable      (control account)
└── 2200 VAT Payable

3000 Equity
└── 3100 Owner Capital

4000 Revenue
├── 4100 Product Sales
└── 4200 Service Revenue

5000 Expenses
├── 5100 Salary
├── 5200 Rent
└── 5300 Utilities

For payment methods like bKash, Nagad, or card gateways, model them as real financial accounts rather than free-text strings — and route gateway payments through a clearing account so gateway fees reconcile cleanly:

Customer pays ৳10,000 by card:
  DR Card Clearing Account    10,000
      CR Accounts Receivable          10,000

Bank settles, minus a ৳200 gateway fee:
  DR Bank                      9,800
  DR Payment Gateway Fee         200
      CR Card Clearing Account         10,000

Card Clearing Account balance = 0

✅ Best Practices Checklist

Once these five are correct, Sales, Purchase, POS, Inventory, Tax, and Expense modules can all be built on top of the same financial foundation, with the accounting engine as the central authority rather than `invoice`, `payment`, `sales`, and `purchase` tables reaching directly into each other.

Final words

The most important architectural rule: don't make the invoice table responsible for everything. Business modules generate financial events; a dedicated accounting engine records and reconciles those events. That separation is what makes an ERP scale, audit cleanly, and survive years of feature growth without turning into a tangle of ad-hoc status flags.