About Experience Engineering Projects Infrastructure Blog Contact
Accounting Curriculum Blueprint πŸ“š 15 Levels Β· 35 Phases

Accounting to ERP: The Complete Learning Roadmap

Published: Aug 27, 2026

πŸ“‹ Table of Contents

πŸ“– How to Use This Roadmap

This page is not an accounting article β€” it's the content blueprint behind one. Every topic below will eventually become its own full article on this blog, written to the same standard as the already-published Invoice vs Payment: The Complete ERP Accounting Architecture β€” which is itself the fully-expanded version of Level 10 below.

The curriculum teaches accounting as two layers of the same thing: the traditional discipline (debits, credits, ledgers, statements) and the modern ERP system that automates it (documents, journal engines, subledgers, reconciliation). Every topic, at every level, is meant to be traceable through one chain:

Business Event
β†’
Business Document
β†’
Accounting Event
β†’
Journal Entry
β†’
Subledger
β†’
General Ledger
β†’
Trial Balance
β†’
Financial Statements
πŸ’‘ The rule every level follows: never introduce an ERP or architecture concept until the plain accounting concept underneath it has been taught first, and never teach a plain accounting concept without eventually showing where it lives in an ERP. Levels 1–9 build the accounting foundation; Levels 10–15 rebuild the same knowledge as a system.

πŸ”­ The Six Perspectives Every Article Must Answer

Because the ultimate goal of this series is to understand accounting well enough to design an ERP accounting module β€” not just use one β€” every single article, at every level, must answer the same transaction from six different vantage points. Skipping any one of them is what turns a topic into "just theory" or "just a how-to click guide" instead of a complete picture.

Accountant PerspectiveWhat happened financially?
↓
ERP User PerspectiveWhat document did I create?
↓
ERP Functional PerspectiveWhat business rule was triggered?
↓
Accounting PerspectiveWhat debit/credit was generated?
↓
System Architecture PerspectiveWhat records/relationships were created?
↓
Audit PerspectiveCan we prove what happened?

Grounded in one concrete transaction β€” ABC Trading Ltd. posts a ৳55,000 credit sale β€” the six perspectives look like this:

PerspectiveAnswersTemplate field it fillsFor this transaction
AccountantWhat happened financially?Business ScenarioSold goods worth ৳55,000 to a customer on credit
ERP UserWhat document did I create?Documents InvolvedA Sales Invoice, e.g. INV-2026-000123, posted in the system
ERP FunctionalWhat business rule was triggered?Accounting Flow / ERP WorkflowThe "Invoice β†’ AR" posting rule fires automatically on confirm
AccountingWhat debit/credit was generated?Debit/Credit ConceptsDR Accounts Receivable 55,000 / CR Sales Revenue 50,000 / CR VAT Payable 5,000
System ArchitectureWhat records/relationships were created?Database Relationship1 Invoice row, N InvoiceLine rows, 1 JournalEntry + its JournalEntryLine rows, all FK'd to the Customer
AuditCan we prove what happened?Real-World ERP ScenarioAn AuditLog row: who posted it, when, the reference document, old/new values
πŸ’‘ Why all six, every time: a reader who only gets the Accountant and Accounting perspectives learns bookkeeping but not ERP design. A reader who only gets the ERP User and Functional perspectives learns to click buttons but not why the numbers are trustworthy. All six together is what separates "accounting knowledge" from "the knowledge needed to design an ERP accounting module" β€” the explicit long-term goal of this series.

🏒 The Running Case Study: ABC Trading Ltd.

One fictional company is reused across every level so a reader can watch a single, coherent set of books grow in complexity from page one to the capstone. It opens with a balanced accounting equation on day one:

AccountOpening balanceType
Cash৳100,000Asset
Bank৳500,000Asset
Inventory৳300,000Asset
Total Assets৳900,000
Capital৳900,000Equity

From here, each level introduces the next layer the company needs β€” its first customer and supplier at Level 5–6, its first VAT return at Level 7, its first depreciating asset at Level 9, its first branch and foreign-currency invoice at Level 13 β€” so that by Level 15 the reader has effectively watched one company's books mature from a single trial balance into a full multi-branch, multi-currency, audited ERP ledger.

🌳 The Knowledge Tree: 15 Subject-Matter Categories

The 15 Levels below organize the series by difficulty β€” what a reader needs to already know. This tree organizes the same content by subject β€” what a reader is trying to look up. They're two lenses on one knowledge base, not two competing structures: every branch below links to the level(s) that actually teach it, so the blog reads as a connected tree rather than a hundred unrelated posts.

01Fundamentals
What is Accounting?AssetsLiabilitiesEquityRevenueExpenses
Maps to Level 1 β€” Absolute Beginner
02Double Entry
DebitCreditJournalLedgerTrial Balance
Maps to Level 3 β€” Double-Entry Accounting
03Chart of Accounts
Account numberingAccount groupsControl accounts
Maps to Level 2 β€” Basic Bookkeeping (Phase 3)
04General Ledger
PostingAccount balanceGL reconciliation
Maps to Level 2 β€” Basic Bookkeeping (Phase 4)
05Sales Accounting
Sales OrderDeliveryInvoiceARPayment
Maps to Level 6 β€” Sales & Purchase Accounting (Phase 5)
06Purchase Accounting
Purchase OrderReceiptSupplier BillAPPayment
Maps to Level 6 β€” Sales & Purchase Accounting (Phase 6)
07Invoice & Payment
Full PaymentPartial PaymentMultiple PaymentsOverpaymentAdvanceUnallocatedRefundReversal
Maps to Level 5 β€” AR & AP and Level 10 β€” ERP Accounting Β· fully published: Invoice vs Payment
08Reconciliation
ARAPBankGL
Maps to Level 4 β€” Practical Business Accounting (bank) and Level 14 β€” System Architecture (Phase 30, full reconciliation)
09Inventory Accounting
ValuationCOGSStock adjustment
Maps to Level 7 β€” Tax & Inventory Accounting (Phase 16)
10Tax Accounting
Input taxOutput taxTax reporting
Maps to Level 7 β€” Tax & Inventory Accounting (Phase 15)
11Fixed Assets
CapitalizationDepreciationDisposal
Maps to Level 9 β€” Advanced Accounting (Phase 17)
12Accrual & Deferral
Accrued expense/revenuePrepaid expenseDeferred revenue
Maps to Level 8 β€” Financial Statements (Phase 18)
13Financial Statements
Balance SheetIncome StatementCash Flow
Maps to Level 8 β€” Financial Statements (Phase 20)
14Advanced Accounting
Cost accountingManagement accountingMulti-branchMulti-companyMulti-currency
Maps to Level 9 β€” Advanced Accounting and Level 13 β€” Enterprise Accounting
15ERP Accounting
ERP Document LifecycleAccounting EngineSubledgerGLAudit TrailSAP ConceptsOdoo ConceptsAccounting System Architecture
Maps to Level 10, Level 11, Level 12, and Level 14

πŸ—ΊοΈ The 15-Level Roadmap at a Glance

Click any level to jump to its phase breakdown.

L1Absolute Beginner
β†’
L2Basic Bookkeeping
β†’
L3Double-Entry
β†’
L4Practical Accounting
β†’
L5AR / AP
β†’
L6Sales / Purchase
β†’
L7Tax / Inventory
β†’
L8Financial Statements
β†’
L9Advanced Accounting
β†’
L10ERP Accounting
β†’
L11ERP Architecture
β†’
L12SAP / Odoo Concepts
β†’
L13Enterprise Accounting
β†’
L14System Architecture
β†’
L15Advanced ERP (Capstone)
LEVEL 1

Absolute Beginner

Understand what accounting is and internalize the five account types and the accounting equation before a single journal entry is introduced.

PhasePrerequisitesTopics covered
Phase 1
Accounting Fundamentals		None β€” curriculum entry pointWhat is Accounting; Accounting vs Bookkeeping; Assets, Liabilities, Equity, Revenue, Expenses, Profit, Loss; Accounting Equation; Debit, Credit, Account; Chart of Accounts; Account Types; Normal Balance; Journal, Ledger, General Ledger, Trial Balance; Financial Statements; Fiscal Year, Accounting Period; Opening/Closing Balance

Business scenario: ABC Trading Ltd.'s day-one balance sheet β€” Cash 100,000 + Bank 500,000 + Inventory 300,000 = Capital 900,000 β€” read purely as Assets = Equity, the accounting equation in its simplest form, before any transaction happens.

Diagram to build: a balance-scale visual for Assets = Liabilities + Equity, plus a five-box "account type" reference card with each type's normal balance side marked.

⚠️ Common mistake: treating "debit" and "credit" as synonyms for "increase" and "decrease" before the account-type-dependent rule is taught in Level 3 β€” this is the single most common misconception to defuse early.

Connects to: nothing precedes it. Feeds directly into Level 2 once the five account types are internalized.

LEVEL 2

Basic Bookkeeping

Learn to structure a Chart of Accounts and post transactions into a ledger before tackling formal double-entry theory.

PhasePrerequisitesTopics covered
Phase 3
Chart of Accounts		Level 1What/why COA; account numbering & hierarchy; account groups; control accounts; cash/bank accounts; AR/AP control accounts; revenue, COGS, expense, tax, fixed asset, accumulated depreciation, liability, equity, suspense, clearing accounts; retained earnings
Phase 4
General Ledger		Phase 3What is GL; GL vs subledger; posting; journal & journal line; account balance; debit/credit balance; period, opening, closing balance; GL reporting; control accounts; GL reconciliation; trial balance

Business scenario: ABC Trading Ltd.'s numbered COA β€” 1000 Cash, 1100 Bank, 1200 Accounts Receivable, 1300 Inventory, 2000 Accounts Payable, 3000 Capital, 4000 Sales Revenue, 5000 COGS β€” with the Level 1 opening balances posted as the very first GL entry.

Diagram to build: a Chart-of-Accounts tree (Assets/Liabilities/Equity/Revenue/Expenses as root nodes), and a Subledger β†’ Control Account β†’ General Ledger flow diagram.

⚠️ Common mistake: numbering accounts ad hoc instead of in ranges (1000s = Assets, 2000s = Liabilities…), which makes control-account mapping and reporting brittle the moment the COA grows.

Connects to: Level 1 before it; Level 3 supplies the posting mechanics for everything recorded here.

LEVEL 3

Double-Entry Accounting

Master the debit/credit rule for every account type and post a full sequence of transactions to a balanced trial balance.

PhasePrerequisitesTopics covered
Phase 2
Double-Entry Accounting		Level 1, Level 2Meaning of double-entry; why every transaction has two sides; traditional debit/credit rules; modern accounting-equation approach; asset/liability/equity/revenue/expense account behavior; journal entries; posting to ledger; trial balance; detecting errors; balanced journal entries

Business scenario β€” ABC Trading Ltd.'s first month, ten transactions:

EventDebitCredit
Owner invests 100,000Cash 100,000Capital 100,000
Buy inventory for cash 20,000Inventory 20,000Cash 20,000
Buy inventory on credit 30,000Inventory 30,000Accounts Payable 30,000
Sell goods for cash 15,000Cash 15,000Sales Revenue 15,000
Sell goods on credit 25,000Accounts Receivable 25,000Sales Revenue 25,000
Pay supplier 10,000Accounts Payable 10,000Cash 10,000
Receive customer payment 12,000Cash 12,000Accounts Receivable 12,000
Pay salary 20,000Salary Expense 20,000Cash 20,000
Pay rent 10,000Rent Expense 10,000Cash 10,000
Receive bank loan 500,000Bank 500,000Loan Payable 500,000

Diagram to build: a T-account for each account type touched above, and a debit/credit decision table (increase/decrease by account type) β€” the same pattern already used in the published double-entry section.

⚠️ Common mistake: posting an entry where debits β‰  credits and not catching it until the trial balance quietly fails to balance weeks later.

Connects to: Level 2 (accounts to post into) before it; Level 5 and Level 6 after it are simply double-entry applied to specific business processes.

LEVEL 4

Practical Business Accounting

Apply double-entry to real cash and bank movements β€” the first genuinely operational accounting a business performs daily.

PhasePrerequisitesTopics covered
Phase 13
Bank & Cash Accounting		Level 3Cash receipt/payment; bank receipt/payment; bank/cash transfer; bank charges; payment gateway & clearing; cash shortage/overage; unidentified bank transaction; duplicate payment; payment reversal
Phase 14
Bank Reconciliation		Phase 13What/why reconciliation; bank statement vs ERP bank ledger; matched/unmatched transaction; outstanding cheque; bank charge; interest income; unknown deposit; duplicate transaction; timing difference; reconciliation adjustment & status

Business scenario: ABC Trading Ltd.'s bank statement shows a ৳500 bank charge and a ৳2,000 deposit not yet in the ERP β€” walk through matching, then posting both adjustments until the bank ledger and statement agree.

Diagram to build: a reconciliation diagram β€” two parallel ledgers (bank statement vs ERP bank account) converging into a matched/unmatched split, then an adjustment loop.

⚠️ Common mistake: "fixing" a reconciliation by editing the original bank transaction instead of posting a separate reconciling adjustment entry that preserves both records.

Connects to: Level 3 before it; Level 5 after it reuses this exact reconciliation logic for customers and suppliers.

LEVEL 5

Accounts Receivable & Accounts Payable

Track what customers owe and what the business owes suppliers as running subledger balances, never as a single mutable field on the invoice.

PhasePrerequisitesTopics covered
Phase 7
Accounts Receivable		Level 4What is AR; customer balance; invoice; due date; payment terms; outstanding amount; partial/full/overpayment; advance payment; unallocated payment; payment allocation; credit note; refund; write-off; bad debt; AR aging; customer statement; collection process; reconciliation
Phase 8
Accounts Payable		Phase 7 (mirror)Outstanding AP; partial/full settlement; overpayment; supplier advance; credit balance; refund; payment reversal; write-off β€” every AR concept mirrored to the supplier side

Business scenario: a ৳1,000 customer invoice run through Payment = 0 / 1 / 100 / 250 / 500 / 700 / 900 / 999 / 1,000 / 1,100 / 1,500, each mapped to UNPAID β†’ PARTIALLY_PAID β†’ PAID β†’ PAID + credit β€” then the identical table re-run for a ৳1,000 supplier bill.

Diagram to build: a running-balance customer/supplier statement, and an AR/AP aging bucket chart (Current / 30 / 60 / 90+ days).

⚠️ Common mistake: storing a single paid_amount field on the invoice instead of a subledger of allocations β€” it breaks the moment one payment must settle two invoices.

Connects to: Level 4 before it; Level 6 after it is where AR and AP balances actually get created. Fully expanded in Invoice vs Payment: The Complete ERP Accounting Architecture.

LEVEL 6

Sales & Purchase Accounting

Walk the full document chain that creates the AR and AP balances Level 5 assumed already existed.

PhasePrerequisitesTopics covered
Phase 5
Sales Accounting		Level 5Customer; quotation; sales order; delivery; sales invoice; credit note; debit note; customer payment; payment allocation; customer statement; AR aging; bad debt; write-off; refund
Phase 6
Purchase Accounting		Phase 5 (mirror)Supplier master; purchase order; goods receipt; supplier invoice; accounts payable; supplier payment; supplier advance; supplier credit; debit note; purchase return; payment allocation; supplier reconciliation; AP aging

Business scenario: ABC Trading Ltd. quotes a customer ৳50,000, converts it to a sales order, delivers (inventory βˆ’20 units, COGS ৳35,000), and invoices ৳55,000 including VAT β€” mirrored by buying that same inventory from a supplier for ৳100,000 + VAT.

Diagram to build: the Quotation β†’ Sales Order β†’ Delivery β†’ Invoice flow (reuse the diagram already built for the published Sales Flow section) and its Purchase-side mirror.

⚠️ Common mistake: treating the Sales Order as if it already creates a receivable β€” it doesn't; only the posted Invoice does.

Connects to: Level 5 before it; Level 7 after it covers the Tax and Inventory accounts every line of these documents ultimately touches.

LEVEL 7

Tax & Inventory Accounting

Go deeper into the two accounts every sales/purchase line touches β€” tax and inventory β€” beyond what Level 6 needed for the basic flow. (Bank mechanics were already covered at Level 4.)

PhasePrerequisitesTopics covered
Phase 15
Tax Accounting		Level 6Sales tax, VAT; purchase VAT; input/output tax; tax payable/receivable; tax-inclusive/exclusive pricing; tax invoice; tax credit note; tax adjustment; tax reporting
Phase 16
Inventory Accounting		Level 6Inventory asset; goods receipt; valuation (FIFO, weighted average, standard cost); COGS; stock issue; purchase/sales return; inventory adjustment/write-off; perpetual vs periodic inventory

Business scenario: ABC Trading Ltd. sells goods for ৳1,000 + 15% VAT = ৳1,150; under perpetual inventory the same sale also posts DR COGS / CR Inventory at the ৳600 cost of the units sold β€” two journal entries generated from one invoice.

Diagram to build: a "one invoice, two journal entries" side-by-side diagram (revenue-recognition entry + COGS/inventory entry), and a FIFO-vs-weighted-average worked comparison table.

⚠️ Common mistake: posting VAT into the Sales Revenue account instead of a separate VAT Payable liability, overstating both revenue and tax exposure.

Connects to: Level 6 before it; Level 8 after it, once every account has a full period's activity to close.

LEVEL 8

Financial Statements

Turn a fully populated trial balance into accruals-adjusted, closed-period financial statements.

PhasePrerequisitesTopics covered
Phase 18
Accruals & Deferrals		Level 7Accrued expense/revenue; prepaid expense; deferred revenue; month-end adjustment; reversing entry; recurring journal
Phase 19
Period-End & Closing		Phase 18Full month-end workflow (AR β†’ AP β†’ bank β†’ inventory reconciliation β†’ depreciation β†’ accruals β†’ prepayments β†’ tax β†’ adjustments β†’ trial balance β†’ financial statements β†’ closing); open/closed/locked periods; backdated transactions; reopening
Phase 20
Financial Statements		Phase 19Balance Sheet; Income Statement; Cash Flow Statement; Statement of Changes in Equity; Trial Balance; General Ledger; AR/AP aging β€” and exactly how journal entries flow into each

Business scenario: ABC Trading Ltd. accrues an unpaid ৳5,000 electricity bill at month-end (DR Utilities Expense / CR Accrued Liabilities) so the Income Statement reflects the cost in the month it was incurred, not the month it's paid.

Diagram to build: the month-end closing workflow as a linear flowchart (same visual language as the settlement decision flowchart), and a journal-entry-to-financial-statement-line tracing diagram.

⚠️ Common mistake: closing a period before bank and AR/AP reconciliations are complete, then having to reopen it β€” reopening should require explicit authorization, never a casual undo.

Connects to: Level 7 before it; Level 9 after it operates only on top of a correctly closed period.

LEVEL 9

Advanced Accounting

Extend the closed-period foundation into fixed assets, cost accounting, and management accounting.

PhasePrerequisitesTopics covered
Phase 17
Fixed Asset Accounting		Level 8Asset purchase; capitalization; asset register; depreciation; accumulated depreciation; useful life; residual value; disposal; sale; impairment; transfer; revaluation
Phase 21
Cost Accounting		Level 8Cost center; profit center; department; project; cost allocation; direct/indirect cost; fixed/variable cost; COGS; manufacturing cost; overhead; budget vs actual; variance analysis
Phase 22
Management Accounting		Phase 21Budgeting; forecasting; cost analysis; profitability; margin; contribution margin; break-even; department/product/customer/branch profitability

Business scenario: ABC Trading Ltd. capitalizes a ৳240,000 delivery van with a 5-year useful life and ৳0 residual value; straight-line depreciation posts DR Depreciation Expense 4,000 / CR Accumulated Depreciation 4,000 every month.

Diagram to build: an asset lifecycle flowchart β€” Purchase β†’ Capitalize β†’ Depreciate Monthly β†’ Dispose/Sell β€” in the same style as the invoice lifecycle diagram.

⚠️ Common mistake: expensing a capital purchase directly instead of capitalizing and depreciating it, distorting both the Balance Sheet and one month's Income Statement.

Connects to: Level 8 before it; Level 10 after it turns all of this from manual monthly journals into ERP-automated rules.

LEVEL 10

ERP Accounting

Rebuild everything learned so far as the engine an ERP runs automatically β€” this level is where "accounting user" knowledge becomes "accounting system" knowledge.

PhasePrerequisitesTopics covered
Phase 9
Invoice & Payment Relationship		Level 9Payment received vs payment allocated; 1↔1, 1↔many, many↔1 allocation; payment without invoice; overpayment; advance; unallocated payment; wrong allocation; reversal; refund; credit note; write-off
Phase 10
Document Lifecycle		Phase 9DRAFT β†’ SUBMITTED β†’ APPROVED β†’ POSTED β†’ PARTIALLY SETTLED β†’ SETTLED β†’ REVERSED β†’ CANCELLED for every document type; document status vs accounting status
Phase 11
Accounting Journal Engine		Phase 10Business Event β†’ Accounting Rule β†’ Journal Entry β†’ Journal Lines β†’ Debit/Credit β†’ Posting β†’ GL, applied to every transaction type covered so far
Phase 12
Subledger Accounting		Phase 11AR/AP/Inventory/Fixed Asset/Bank/Cash subledgers; subledger balance vs GL control account; reconciliation between the two
βœ… Already fully published: this entire level is expanded in Invoice vs Payment: The Complete ERP Accounting Architecture β€” its relationship map, invoice/payment lifecycle state machine, activity swimlane, settlement flowchart, and the ৳1,000-invoice scenario playbook are the reference implementation every later level's diagrams should match in style.
⚠️ Common mistake: modeling invoice.payment_id as a single foreign key instead of a many-to-many allocation table.

Connects to: Level 9 before it; Level 11 after it zooms out from one module to the whole ERP system.

LEVEL 11

ERP Architecture

Zoom out from the invoice/payment module to how every ERP entity interacts across the whole system.

PhasePrerequisitesTopics covered
Phase 26
ERP Accounting Architecture		Level 10How Customer, Supplier, Product, Warehouse, Sales/Purchase Order, Delivery, Goods Receipt, Invoice, Payment, Payment Allocation, Journal Entry, Journal Line, Account, Chart of Accounts, Fiscal Period, Tax, Currency, Bank, Cash, Cost Center, and Company interact
Phase 27
ERP Database Concept		Phase 26Conceptual entities and cardinalities (1:1, 1:N, N:M): Customer β†’ Invoice β†’ Invoice Lines ↔ Payment Allocation ↔ Payment β†’ Journal Entry β†’ Journal Lines β†’ GL Account, and the Supplier-side mirror
Phase 28
Accounting Event vs Business Document		Phase 27Sales Order β‰  accounting entry; Delivery β‰  necessarily revenue recognition; Invoice = financial event; Payment = settlement event; Payment Allocation = settlement relationship; why ERP architecture deliberately separates these

Business scenario: trace one ABC Trading Ltd. sales order through every entity it touches end to end, marking exactly where β€” and only where β€” a journal entry gets generated.

Diagram to build: a full entity-relationship diagram covering all ~19 entities from Phase 26, extending the smaller relationship map already built at Level 10.

⚠️ Common mistake: giving the invoice table responsibility for AR balance, payment status, and GL posting all at once instead of letting each concern live in its own entity.

Connects to: Level 10 before it; Level 12 after it grounds this architecture in real ERP products.

LEVEL 12

SAP/Odoo Concepts

Map every universal concept taught so far onto the vocabulary of two real ERP products, without assuming they implement anything identically.

PhasePrerequisitesTopics covered
Phase 33
SAP/Odoo Conceptual Mapping		Level 11Customer/Vendor; Chart of Accounts; Journal & Journal Entry; AR/AP; Invoice/Payment; Reconciliation; Fiscal Position; Tax; Bank/Cash Journal; Accounting Period; Cost Center; Analytic Accounting; Asset Accounting β€” universal concept vs SAP-style term vs Odoo-style term

Business scenario: "Payment Allocation" (universal) is conceptually similar to SAP's clearing of open items against a payment document, and to Odoo's reconciling a payment move against an invoice move β€” same underlying concept, different product vocabulary.

Diagram to build: a three-column comparison table (Universal Concept | SAP-style term | Odoo-style term) β€” see the reference table later on this page.

⚠️ Common mistake: presenting SAP or Odoo terminology as if it were the universal accounting concept itself, which confuses readers when they later work with a third ERP.

Connects to: Level 11 before it; Level 13 after it needs this shared vocabulary to discuss concrete multi-company/multi-currency setups.

LEVEL 13

Enterprise Accounting

Scale a single-company, single-currency ledger up to multi-branch, multi-company, and multi-currency operations.

PhasePrerequisitesTopics covered
Phase 23
Multi-Branch Accounting		Level 12Company, branch, warehouse, department, cost center; branch revenue/expense/inventory/cash/bank; inter-branch transfer and accounting
Phase 24
Multi-Company Accounting		Phase 23Parent company; subsidiary; intercompany transaction/invoice/payment/receivable/payable; elimination; consolidation
Phase 25
Multi-Currency Accounting		Phase 24Transaction vs base/company currency; exchange rate; foreign currency invoice/payment; realized/unrealized gain-loss; currency revaluation

Business scenario: ABC Trading Ltd. opens a Chittagong branch and later a Singapore subsidiary; an inter-branch stock transfer and a USD invoice to the Singapore entity both need accounting treatment beyond a single-company, single-currency ledger.

Diagram to build: a multi-entity structure diagram (Parent β†’ Subsidiary β†’ Branch β†’ Cost Center) with intercompany transaction arrows and an elimination step at consolidation.

⚠️ Common mistake: recording an intercompany invoice as if the counterparty were an ordinary external customer, so it never gets eliminated at consolidation and inflates group revenue.

Connects to: Level 12 before it; Level 14 after it, where audit and reconciliation controls have to scale across every one of these entities.

LEVEL 14

Accounting System Architecture

Formalize the audit trail, reconciliation discipline, and error-correction rules that keep a multi-entity ERP's books trustworthy.

PhasePrerequisitesTopics covered
Phase 29
Audit Trail		Level 13Who created/approved/posted/modified/cancelled/reversed a record; timestamp; old/new value; reason; reference document; approval history; why posted records are reversed, never deleted
Phase 30
Reconciliation		Phase 29AR, AP, bank, cash, inventory, subledger-vs-GL, tax, and intercompany reconciliation, each with source A, source B, expected vs actual, difference, investigation, adjustment, approval, resolution
Phase 31
Error & Correction Accounting		Phase 30Wrong amount/account/customer/supplier/invoice/allocation; duplicate invoice/payment; missing transaction; incorrect tax/exchange rate/date; backdating β€” corrected via adjustment, reversal, credit note, debit note, or write-off, never a silent edit

Business scenario: a posted ABC Trading Ltd. invoice is discovered to reference the wrong customer a week after posting β€” walked through as a reversal plus correct re-issue, with the audit log showing both the original entry and the fix.

Diagram to build: a generic reconciliation diagram (Source A vs Source B β†’ matched/unmatched β†’ investigate β†’ adjust β†’ approve β†’ resolved), reusable across all seven reconciliation types in Phase 30.

⚠️ Common mistake: "fixing" a posted error by editing the historical journal entry in place, breaking every report and audit trail that already referenced it.

Connects to: Level 13 before it; Level 15 after it stress-tests this architecture against real, messy scenarios.

LEVEL 15

Advanced ERP Accounting (Capstone)

Bring every prior level together against the full catalogue of real-world scenarios and close out the running ABC Trading Ltd. case study.

PhasePrerequisitesTopics covered
Phase 32
Advanced Real-World Scenarios		Level 14Partial/multiple/over/under-payment, advance, unallocated payment, reversal, refund, credit/debit note, discount, write-off, bad debt, payment gateway & fee, bank fee, cash short/over, foreign currency, many-to-many allocation, intercompany payment, tax and period-end adjustment β€” each with business situation, documents, sequence, DR/CR, AR/AP impact, GL impact, settlement impact, and audit impact
Phase 34
Workflow & Diagram Guidance		Phase 32Which diagram type (flowchart, activity, sequence, ERD, accounting-flow, lifecycle, posting, allocation, reconciliation) fits which topic, and what actors/documents/decision points/entities each must show
Phase 35
Complete Business Case		Phase 34ABC Trading Ltd., followed end-to-end from its opening balance through every phase above β€” the single running thread tying the entire curriculum together

Business scenario: this level introduces no new numbers β€” it is where every prior level's ABC Trading Ltd. entries are assembled into one continuous general ledger and closed into one final set of financial statements.

Diagram to build: none new β€” the deliverable is the assembled diagram library from every prior level, indexed against the one company.

⚠️ Common mistake: treating "advanced scenarios" as edge cases to bolt on later instead of designing the Level 10 data model β€” many-to-many allocation, derived balances, typed adjustments β€” so that every one of these scenarios already falls out of it for free. That is exactly the conclusion reached in the scenario playbook of the published Invoice vs Payment article.

Connects to: Level 14 before it; nothing after it β€” this is the capstone the entire 15-level roadmap builds toward.

πŸ“ The Article Content Template

Every individual topic in the roadmap above expands into its own article using the same 28-field template, so the series reads as one consistent body of work no matter which topic or level a reader lands on first. The fields aren't arbitrary β€” most of them exist specifically to force the six perspectives onto the page.

FieldPurpose
Topic Number / NamePosition in the roadmap and a precise, searchable title
Difficulty / CategoryWhich of the 15 levels it belongs to, and its phase grouping
PrerequisitesExact topics a reader must already know β€” never assumed silently
Learning ObjectiveThe one capability the reader should have by the end
Why This Topic MattersThe real-world cost of getting it wrong
Core / Accounting / ERP ConceptsVocabulary introduced, split by traditional-accounting vs ERP-system framing
Business Scenario / Numerical ExampleGrounded in the ABC Trading Ltd. case study wherever possible
Debit/Credit ConceptsThe journal entry(ies) the scenario produces
Documents InvolvedWhich business documents the topic touches (invoice, PO, GRN, etc.)
Accounting Flow / ERP WorkflowBusiness Event β†’ Document β†’ Accounting Event β†’ Journal Entry β†’ GL, and who performs each step
AR/AP Relationship / GL RelationshipHow the topic affects subledger balances and the control accounts above them
Financial Statement ImpactWhich statement line moves, and in which direction
Database RelationshipConceptual entities and cardinalities β€” never production code
Required DiagramWhich diagram type this topic needs (see Level 15, Phase 34)
Common MistakesThe specific, concrete failure mode β€” not generic advice
Real-World ERP ScenarioHow the concept shows up in a live system, not just in theory
SAP / Odoo Conceptual ReferenceMapped per the comparison table below β€” never fabricated
Advanced ExtensionWhere the topic goes if the reader wants to go deeper immediately
Related / Next Recommended TopicExplicit links forward and sideways in the roadmap

βš–οΈ SAP vs Odoo: Concept vs Vocabulary

These mappings are conceptual starting points for a writer, not a claim that SAP and Odoo implement the underlying process identically β€” they don't. Before any article asserts specific menu paths, transaction codes, or module names, verify them against current official SAP and Odoo documentation; product UIs and terminology change across versions.

Universal accounting conceptSAP-style framingOdoo-style framing
Customer / SupplierBusiness Partner roles (Customer / Vendor)A single Contact record flagged as Customer and/or Vendor
Chart of AccountsOperating Chart of Accounts assigned to a company codeChart of Accounts assigned per company
Journal EntryAccounting Document / FI postingJournal Entry (move) made of journal items
Payment AllocationClearing open items against a payment documentReconciling a payment move against an invoice move
ReconciliationAccount clearing / open-item managementBank/account reconciliation on a journal
Tax handlingTax procedure / condition-based tax determinationFiscal Position mapping taxes and accounts
Bank/Cash recordingBank accounting sub-module (house banks)Bank and Cash Journals
Accounting PeriodPosting period, opened/closed per company codeFiscal Year with lock dates
Cost Center / Analytic AccountingControlling (CO) cost centers & profit centersAnalytic Accounts & Analytic Tags
Asset AccountingAsset Accounting (FI-AA) sub-ledgerAssets module with depreciation boards
⚠️ Verification instruction for the writing agent: whenever a future article states a specific SAP or Odoo feature, screen, or field name, cross-check it against the current official documentation before publishing. Do not fabricate transaction codes, menu paths, or version-specific behavior β€” where uncertain, describe the concept generically and flag the product-specific detail as "verify against current docs."

βœ… Editorial Guidelines for This Series

  • Every article must explicitly answer all six perspectives β€” Accountant, ERP User, ERP Functional, Accounting, System Architecture, Audit β€” not just the debit/credit one.
  • Explain the business event before the journal entry it produces β€” never the reverse.
  • Always show both the debit and the credit; never state one side alone.
  • Distinguish document status from accounting status in every lifecycle discussion.
  • Distinguish payment received from payment allocated β€” the single most common modeling error in the whole curriculum.
  • Distinguish subledger balances from the General Ledger control account they roll up into.
  • Cover both AR and AP, both Sales and Purchase β€” never document one side and assume the mirror is obvious.
  • Explain every concept from both the accounting user's perspective and the ERP system's perspective.
  • Never recommend deleting a posted transaction β€” teach reversal and correction instead.
  • Never present SAP or Odoo terminology as if it were the universal accounting concept itself.
  • Increase technical depth gradually β€” an advanced topic without its prerequisites linked is an incomplete article.

Together with the content template above, these rules are what keep a 35-phase, hundreds-of-topics series readable as one coherent body of work rather than a pile of disconnected posts β€” the same standard the Invoice vs Payment article was written to.

← Back to Blog
↑