How to learn ERP systems: a 90-day plan

What learning an ERP system actually means

Learning an ERP system means learning how one shared database turns business events into accounting: which master data a process needs, which document records each step, what journal that document posts, and which report shows the result. It matters because employers hire people who can run a process end to end and explain the numbers, not people who have memorised menu paths.

An ERP (enterprise resource planning) system joins sales, purchasing, inventory, finance, payroll and often projects and maintenance in one application with one ledger. Every product works differently on screen, but the logic underneath is the same everywhere: a sale reduces stock and creates a receivable, a purchase increases stock and creates a payable, and a period close locks what has been reported. Learn that logic once and every new system becomes a question of where things are, not what they mean.

This guide is written for students, graduates and career-changers. It explains what an ERP looks like from the inside, gives an order for learning the modules, lays out a 90-day self-study plan with exercises you can run end to end, and ends with how to turn the practice into evidence on a CV.

An ERP from the inside: four layers

Almost every ERP screen belongs to one of four layers. If you can say which layer you are looking at, you will rarely be lost.

The layers depend on each other in one direction. Bad master data produces wrong documents, wrong documents produce wrong postings, and wrong postings produce wrong reports. When a report looks wrong, experienced users work backwards through the layers: report, posting, document, master data. Beginners tend to fix the report with a manual journal, which hides the real error and makes the next month wrong again.

• Configuration: the settings that rarely change, such as the chart of accounts, tax rates, fiscal years and periods, branches or locations, numbering sequences and the account mapping that tells each document which ledger accounts to hit.
• Master data: the records reused by many transactions, such as customers, suppliers, products, price lists, employees and bank accounts. A customer's payment terms or a product's tax code is set once and inherited by every document.
• Documents (transactions): the events of the business, such as a quotation, sales order, delivery, invoice, goods receipt, supplier invoice, payment, stock transfer or payroll run. Documents have statuses, and only some statuses post to the ledger.
• Postings and reports: the journals the documents generate, and the trial balance, statements, ageing and stock reports built from them. Reports are read-only views; they never fix anything.

The three end-to-end processes to master

ERP work is organised around a small number of end-to-end processes. Three of them cover most of what a finance or operations role touches, and interviewers ask about them by name. The postings below use euros and an illustrative VAT rate of 20% so that the arithmetic is easy to follow.

Order-to-cash (O2C) runs from a customer's order to money in the bank. The invoice for goods sold at EUR 1,000 plus VAT posts Dr Trade receivables 1,200 / Cr Revenue 1,000 / Cr VAT output 200. If the goods cost EUR 600, the delivery or invoice also posts Dr Cost of sales 600 / Cr Inventory 600. When the customer pays, the receipt posts Dr Bank 1,200 / Cr Trade receivables 1,200 and the receivable is cleared.

Procure-to-pay (P2P) runs from a purchase requisition to paying the supplier. A supplier invoice for goods of EUR 800 plus VAT posts Dr Inventory 800 / Dr VAT input 160 / Cr Trade payables 960, and the payment posts Dr Trade payables 960 / Cr Bank 960. The control at the heart of P2P is the three-way match: the purchase order, the goods received note and the supplier invoice must agree on item, quantity and price before the invoice is approved. Many systems post the goods receipt first to a goods-received-not-invoiced clearing account and clear it when the invoice arrives; find out which way your system works.

Record-to-report (R2R) runs from the individual postings to the published numbers: manual journals for accruals and corrections, bank and balance sheet reconciliations, the period close and the financial statements. O2C and P2P feed R2R, which is why finance teams care so much about how the operational documents are set up.

Which modules to learn, and in which order

Learn the modules in the order that money and goods flow through them, not in menu order. Each step uses what the previous one set up, so by the end you can explain a figure on the balance sheet all the way back to the document that created it.

Leave specialised modules such as manufacturing, maintenance, projects and CRM until the core is solid. They all end in the same ledger, so they are much easier to learn once you know where their postings land.

• General ledger and chart of accounts: account types, normal balances, posting versus heading accounts, fiscal periods and manual journals.
• Sales and receivables: customers, price lists, invoices, credit notes, receipts, customer statements and the ageing report.
• Purchasing and payables: suppliers, purchase orders, goods receipts, supplier invoices, debit notes and payment runs.
• Inventory: products, units, locations, stock valuation, transfers and stock counts, and how the costing method drives cost of sales.
• Cash and bank: bank accounts, receipts and payments, cheques and bank reconciliation.
• Tax: tax rates, how tax is calculated per line, and the tax return report.
• Fixed assets and payroll: asset register and depreciation runs; employees, payroll processing and the payroll journal.
• Reporting and close: trial balance, statements, period locking, year-end close and the audit trail.

Days 1 to 30: foundations

The first month is about vocabulary and configuration. Aim to finish it able to create a small company from nothing and post a balanced journal without help. Spend about an hour a day, and keep a learning log: a running document where you note each task, the screen you used, what went wrong and how you fixed it. That log becomes your CV evidence later.

If you are shaky on double entry, fix that first, because an ERP will not teach it to you; it assumes it. Our guides on debits and credits and on journal entries with examples are the right starting point.

• Week 1: map the menus of your practice system to the four layers above. Write one sentence for each main menu saying what it is for.
• Week 1: build a chart of accounts for a small trading company with about 40 accounts, and check that each has the right type and normal balance.
• Week 2: set up a fiscal year with monthly periods, one tax rate, two customers, two suppliers and five products with cost and selling prices.
• Week 2: post an opening capital journal, Dr Bank 20,000 / Cr Share capital 20,000, and find it in the general ledger and the trial balance.
• Week 3: post five manual journals, including one that the system should reject because it does not balance, and note the exact error message.
• Week 4: run the trial balance and reconcile it by hand to your journals. Explain in writing every balance on it.

Days 31 to 60: run the processes end to end

The second month is about documents rather than journals. The rule for this month: do not post a single manual journal. Every figure must come from a sales, purchase, payment or stock document, so that you learn what each one posts. After each document, open the journal it created and write the entry out in your log as Dr and Cr lines.

Run each process several times with variations, because the variations are where real jobs are hard: a partial delivery, a price difference between the purchase order and the invoice, a return, a customer who pays short, a supplier invoice that arrives before the goods.

• Procure-to-pay: raise a purchase order, receive the goods in two deliveries, post the supplier invoice, pay it, and check that the supplier balance is zero.
• Order-to-cash: invoice three customers, record one full payment, one partial payment and one credit note, and read the ageing report.
• Inventory: sell stock at a price below cost once, and check that cost of sales still uses the costing method rather than the selling price.
• Stock count: record a count that finds two units missing, post the adjustment and trace it to the ledger.
• Tax: run the tax report for the month and reconcile it to the VAT accounts in the trial balance. They should agree to the cent.
• Cash: import or key a bank statement and reconcile the bank account, listing deposits in transit and unpresented payments.

Days 61 to 90: close, control and report

The third month turns you from a user into someone who can be trusted with a ledger. Close the months you have traded, produce statements and look at the system the way an auditor would.

Finish with a capstone: run a second full month for the same company from start to close without notes, time yourself, and write a two-page close memo that explains the profit for the month, the movement in cash and every reconciling item. That memo is the single strongest piece of evidence a self-taught learner can show an employer.

• Post month-end adjustments: an accrued expense, a prepayment released to profit, depreciation on one asset and a provision for a doubtful receivable.
• Close the period, then try to post an invoice dated in it, and record what the system does.
• Correct a posted error the controlled way, by reversal or credit note, rather than by deletion, and find the correction in the audit trail.
• Produce the trial balance, income statement, balance sheet and cash flow statement, and tie retained earnings on the balance sheet to the profit for the period.
• Export the month's data to a spreadsheet and repeat three checks: sales per the ledger against sales per the invoice list, stock per the ledger against the stock valuation report, and the bank balance against the reconciliation.
• Review user roles: list who could create, approve and post a journal, and whether one person could do all three.

The roles ERP skills lead to

ERP skills open several distinct careers, and it helps to know which one you are aiming for because they value different evidence. None of them requires you to know every module; they require depth in a few processes and a clear understanding of how those processes post.

Titles vary by country and by employer, so read job descriptions for the tasks rather than the title. If the advertisement mentions process design, configuration, testing or data migration, it is a systems role; if it mentions reconciliations, close and reporting, it is a finance role that happens to run on an ERP.

• ERP accountant or systems accountant: runs the ledger inside the ERP, owns the close, reconciliations and reporting, and fixes posting problems at source.
• Finance systems analyst: maintains the chart of accounts, account mapping, approval rules, reports and user access, and is the bridge between finance and IT.
• Functional consultant: works for an implementer or a software house, gathers requirements, configures modules, writes test scripts and trains users.
• Implementation specialist: runs the project work of go-live, including data migration, opening balances, cut-over, testing and early support.
• Business process analyst: documents and redesigns processes such as procure-to-pay and order-to-cash, often across several systems.
• Internal auditor or IT auditor: tests controls in the ERP, such as approval limits, segregation of duties, period locks and journal-entry testing.

How to show ERP skills on a CV

Recruiters see many CVs that list an ERP under skills with no evidence. What separates a credible entry is a process, a volume and an outcome. Write the process you ran, the size of the exercise and what you checked, in one line each.

Weak: Familiar with ERP systems. Stronger: Ran procure-to-pay and order-to-cash end to end in a cloud ERP for a practice trading company, 60 documents over two months, reconciled VAT, bank and stock to the trial balance with zero unexplained differences. Stronger still if you can attach the close memo from your capstone or describe it in an interview.

Be honest about the environment. Say practice company or course project when that is what it was; interviewers ask follow-up questions, and a clear explanation of a practice close is worth more than a vague claim about live experience. Keep the system name on the CV, since applicant tracking systems search for it, but put the process names first because they transfer between systems.

• Name the processes: procure-to-pay, order-to-cash, record-to-report, inventory, bank reconciliation, period close.
• Quantify: number of documents, months closed, accounts in the chart, reconciliations completed.
• Show control awareness: period locks, reversals instead of deletions, approval thresholds, audit trail review.
• Show data skills: exporting to a spreadsheet, reconciling system reports to each other, importing master data from a template.

How to practise on a real system

Reading about an ERP is not enough; you need a system where you can post, make mistakes and see the consequences. Good options, in rough order of value: a course or university sandbox, a demo or trial workspace from a vendor, and a practice company inside your employer's system that finance has approved for training.

Never practise in a live production company. Test postings contaminate the ledger and the audit trail, and live systems hold personal data about customers and employees that you have no reason to see. Under the EU General Data Protection Regulation, personal data may be used only for the purposes for which it was collected and must be limited to what is necessary for them (Article 5(1)(b) and (c)); a personal training exercise meets neither test. Invent your own data instead: a fictional company, fictional customers and round numbers you can check in your head.

Whatever system you use, choose one where you can reach the accounting settings, not only the sales screens. A system that hides the account mapping and the journals teaches you data entry. A system that lets you see what each document posts, and lets you close a period, teaches you ERP.

Practising ERP skills in Skyline Nexus ERP

Skyline Nexus ERP is a cloud ERP in which each business is its own workspace, and the ledger, sales, purchasing, bank and close exercises in the 90-day plan map directly to its screens. The general ledger sits under Fiscal Authority, where you can build the chart of accounts with GL codes, account types and posting or heading accounts, set up fiscal years with monthly periods, and post manual journals that cannot be saved unless total debits equal total credits. Once an administrator switches on the auto-post settings, final sales, purchases, payments, expenses and payroll create their journals automatically, so you can open a sale and trace it to Dr accounts receivable, Cr revenue and Cr VAT output.

The close exercises work the same way. Fiscal periods move from Open to Soft Close to Locked and a posting into a closed period is refused; a posted journal is corrected by reversal; and the Audit Trail records who created, approved, posted or reversed each entry with old and new values. Treasury has a bank reconciliation that imports statements in CSV or Excel format and auto-matches items, and the stock accounting method offers FIFO, the IFRS-compatible choice. Students can ask their university, college or business school to apply for sponsored academic access, and individual learners can book a demo through the form on this page.