ERP for Beginners: The Core ERP Modules: Finance, Inventory, Sales, HR, and the Rest

Open any ERP — SAP S/4HANA, Oracle Fusion, NetSuite, Microsoft Dynamics 365 — and after about five minutes of menu exploration, you'll notice something. The organisation of the software looks suspiciously similar no matter whose product you're in.

There will be a Finance module. A Procurement module, though one vendor might call it Purchasing. Inventory. Sales, sometimes labelled Order Management. Manufacturing. HR — though sometimes it lives in its own separate product entirely. And Reporting or Analytics, usually threaded through everywhere.

Seven categories. Different names. Same jobs. If you learn these seven, the menu of any ERP product you'll ever encounter starts to feel familiar, and the job descriptions for ERP consultants start to make sense.

Why the same seven?

Every business, regardless of industry, has a handful of core functions that any ERP has to cover. Money comes in. Money goes out. Things get bought, held, sometimes made, and then sold. People work here and get paid. And someone needs to report on what's happening.

That's the back office of a business, reduced. Any serious ERP has to model all of it, because the whole point of ERP is having one system instead of ten. Leave one category out and the "single source of truth" story collapses immediately — a customer might update in the ERP but not in the missing system, and you're back to disconnected tools.

So every vendor settles, eventually, on roughly the same seven-module shape. The boundaries shift a little — one vendor combines Procurement and Inventory, another splits Sales from CRM — but the underlying categories are durable.

Finance — the backbone

Start with finance, because it sits under everything else.

The finance module covers four sub-areas. General Ledger is the chart of accounts, where every single posting ends up — the company's accounting source of truth. Accounts Payable is what the business owes suppliers. Accounts Receivable is what customers owe the business. And Asset Accounting tracks capitalisation and depreciation of fixed assets like buildings, vehicles, and machinery.

The interesting thing about finance is that it doesn't originate most transactions. It receives them. A sales order in the Sales module automatically posts to AR. A goods receipt in Inventory posts to a consumption or inventory account. A purchase invoice posts to AP. A hire in HR eventually posts to payroll expense. Finance is the passive recipient of what every other module does.

That's why finance is the backbone. When it runs well, the books balance themselves. When other modules have bad master data, finance is where you discover it — the GL starts showing entries that nobody understands.

The supply side: Procurement, Inventory, Manufacturing

Three modules form the physical-ops side of the business — the side that moves materials.

Procurement handles what you buy. Purchase requisitions from internal teams, purchase orders to vendors, goods receipts when deliveries arrive, and invoice verification when the vendor's bill shows up. Vendor master data lives here. Contract terms, pricing agreements, vendor performance.

Inventory tracks what you hold. Stock on hand, bin and location tracking, valuation (moving average or standard cost), cycle counting, reservations against orders. Every goods movement — from the loading dock to the shop floor — is a transaction here.

Manufacturing covers what you make — but only for companies that actually make things. Bills of materials, routings, work centres, production orders, scheduling, operation confirmations. A pure distributor or services firm might never open the Manufacturing module. A food manufacturer lives in it.

These three flow into each other in a predictable rhythm. Buy raw materials through Procurement. Hold them in stock via Inventory. Issue them to a production order from Manufacturing. Finished goods come out the other side and land back in Inventory. Every one of those movements posts a finance consequence automatically.

The revenue side: Sales and CRM

The opposite half is the revenue side. Sales, and sometimes a companion module called CRM.

Sales handles what happens after a deal is won — the quotation, the sales order, the delivery, the invoice. Customer master data and pricing live here. The sales module sits on top of Inventory (needs to know what's in stock) and Finance (creates AR).

CRM — Customer Relationship Management — is the pre-sale side. Leads, opportunities, accounts, campaigns, pipeline forecasting. In some ERPs it's bundled as a module; in others, companies run a separate product like Salesforce or HubSpot that integrates back into the ERP for post-sale handoff. Both approaches work; the question is usually how much of your sales process needs to live in one place.

When both are running, they share one customer master record — no duplicated contact lists, no "is this the same customer?" disambiguation problem.

The surround: HR and Reporting

Two more modules complete the picture.

HR runs the humans. Employee master records, payroll, time and attendance tracking, benefits administration, recruitment, performance reviews, training. For anything past a few hundred employees, HR often graduates into its own dedicated product — SAP SuccessFactors, Oracle HCM, or the giant of the category, Workday. But the shape is always there, inside or alongside the ERP.

Reporting and Analytics is the insight layer. Standard canned reports, ad-hoc query tools, dashboards, KPIs, drill-down from summary to line-item detail. Reporting reads from every other module but never writes a transaction — it's strictly read-only. Modern ERPs embed dashboards directly in the user's home screen (SAP Fiori's launchpad tiles, Oracle Redwood's cards) rather than making you launch a separate reporting application.

When reporting needs get very sophisticated, the field splits again — dedicated business-intelligence tools like Power BI, Tableau, or SAP BusinessObjects take over. They read data out of the ERP and present it through their own visualisation layer. Neither the ERP nor the BI tool can do the other's job perfectly, so they coexist.

The naming problem

Here's the thing that trips up newcomers. Every vendor names these modules differently.

SAP calls finance "FI" and controlling "CO". Oracle calls it "General Ledger" or "Financials". NetSuite just says "Accounting". All three do the same job. SAP's materials management module is "MM"; Oracle's is "Procurement"; NetSuite's is "Inventory Management". SAP's "SD" is Oracle's "Order Management" is NetSuite's "Order Management".

The naming isn't random. Each vendor's history shaped it — SAP's two-letter module codes came from their 1970s German roots; Oracle's names came from their finance-first lineage; NetSuite's simple naming came from being built for smaller companies. But for a newcomer, the naming is pure noise. The jobs are identical.

That's why learning the generic seven-module shape is valuable. Once you know it, any vendor's menu becomes a translation exercise, not a new language.

What these modules buy you

Step back from the names and the details. What does owning all seven of these in one system actually buy a business?

The answer is integration. A sales order created in the Sales module automatically reduces Inventory, creates a finance posting in AR, and — if the product is made-to-order — triggers a Manufacturing production request. All of that happens without anyone typing the same number twice.

That is what ERP is really selling. Not the individual modules, which by themselves aren't that special — most of them existed as standalone products before ERP unified them. What ERP sells is the fact that they're one system, sharing one database, running one consistent set of master data. The seven modules are the map. The integration between them is the terrain.

Episode four takes us to the next layer. Modules are structure. Processes are what flows across them. Order-to-Cash. Procure-to-Pay. Plan-to-Produce. The three big flows every ERP is built to run.