SAP Fresher Interview Preparation - Everything You Need to Crack Your First SAP Job

ERP stands for Enterprise Resource Planning. Companies use ERP because modern businesses have many departments - finance, procurement, sales, HR, manufacturing - and historically each department used its own separate software. This created data silos where information was duplicated, inconsistent, and not available in real time across the organisation. An ERP system like SAP integrates all departments into one platform with a shared database. When a sales order is created, the warehouse inventory updates automatically. When goods are received, the finance team sees the accounting impact immediately. This real-time integration eliminates manual data entry, reduces errors, provides management with accurate reporting, and enables better business decisions.

A T-code, or Transaction Code, is a shortcut that takes you directly to a specific function or screen in SAP without navigating through menus. Instead of clicking through five menu levels, you type the T-code directly in the command field and press Enter. T-codes make SAP much faster for experienced users. Five examples: ME21N - Create Purchase Order (MM). MIGO - Goods Movement/Goods Receipt (MM). FB50 - Enter G/L Account Document (FI). VA01 - Create Sales Order (SD). PA30 - Maintain HR Master Data. You can also use SE11 to view the data dictionary and SE38 to access the ABAP editor.

A Company Code is a legally independent entity that produces its own financial statements - balance sheet and profit and loss account. It is used in financial accounting and represents a legal entity for reporting purposes. For example, Arjun Industries Ltd (Pune) is a company code. A Plant is a physical location - a factory, warehouse, or office - used in logistics operations like procurement and production. A plant always belongs to one company code, but a company code can have multiple plants. For example, company code 1000 (Arjun Industries Ltd) might have plant 1000 (Pune factory) and plant 1100 (Mumbai warehouse). The company code is used for financial reporting; the plant is used for inventory management and production planning.

A Client is the highest organisational level in SAP. It represents an entire independent business environment - a separate data area with its own customising, master data, and transaction data. One SAP system typically has multiple clients for different purposes: a Development client (300) where configuration changes are made, a Quality client (200) where testing is done, and a Production client (100) where live business runs. Data in one client is completely isolated from other clients - a user logged into client 100 cannot see any data from client 200. From a configuration perspective, some settings in SAP are client-independent (they apply to all clients) and some are client-specific (they apply only to the client where they are set). This distinction is important when transporting configuration changes between clients.

Master data is the core business data in SAP that remains relatively stable over time and is used repeatedly across many transactions. It is created once and referenced in transaction documents throughout its lifetime. Examples of master data: Vendor Master (information about a supplier - address, bank details, payment terms - maintained using FK01/XK01), Customer Master (information about a customer - address, credit limit, sales conditions - using XD01/VD01), Material Master (information about a product - description, unit of measure, valuation class, MRP settings - using MM01), and G/L Account Master (financial accounts with their properties - account type, reconciliation account, field status - using FS00). Master data is important because errors in master data affect every transaction that uses it. A wrong payment term in the vendor master means every invoice for that vendor calculates the wrong due date.

Master data is relatively stable information that is created once and reused many times. Examples: vendor master, customer master, material master, G/L account master. This data does not change with every transaction - a vendor's bank account stays the same for years. Transaction data is created every time a business event occurs - it is time-stamped and represents a specific event. Examples: a purchase order raised on 15-May-2026, a goods receipt posted on 18-May-2026, an invoice posted on 20-May-2026, a payment made on 25-May-2026. Transaction data always references master data - the purchase order references the vendor master and the material master. The quality of transaction data depends entirely on the quality of master data. That is why SAP implementations spend significant time on master data governance and cleaning.

A Chart of Accounts (CoA) is a list of all G/L (General Ledger) accounts used by a company to record financial transactions. It defines the structure and numbering of the accounts. In SAP, the Chart of Accounts exists at the client level - it is first defined at the global level and then assigned to individual company codes. One Chart of Accounts can be used by multiple company codes (useful for groups that want standardised reporting). SAP has three types of charts of accounts: the Operating Chart of Accounts (used for daily postings - every company code must have one), the Group Chart of Accounts (used for consolidated group reporting across multiple company codes), and the Country-Specific Chart of Accounts (used for local legal reporting requirements - for example Indian companies may need specific accounts for Companies Act compliance). T-code OB13 to create, T-code OBY6 to assign to company codes.

A Fiscal Year is the accounting period used by a company for financial reporting - it may or may not align with the calendar year. In SAP, a Fiscal Year Variant defines how the year is divided. For Indian companies, the fiscal year typically runs from April to March - April is period 1 and March is period 12. This is different from the calendar year (January to December). SAP allows companies to define their own fiscal year structure using T-code OB29. The fiscal year variant is then assigned to each company code. Some companies use a calendar year fiscal year (January–December) - common in US and European entities. Some use a non-standard year like July–June. SAP handles all of these through the fiscal year variant configuration. When you post a document dated 15-April-2026, SAP automatically assigns it to period 1 of fiscal year 2026 for an Indian company.

The three-way match is SAP MM's internal control that verifies a vendor invoice before it is approved for payment. It compares three documents: the Purchase Order (what was ordered and at what price), the Goods Receipt (what was actually delivered), and the Vendor Invoice (what the vendor says they should be paid). When you enter an invoice in MIRO, SAP automatically compares these three documents. If the invoice quantity matches the GR quantity and the invoice price matches the PO price within the defined tolerance limits, the invoice posts successfully and is released for payment. If the quantities or prices differ beyond tolerance, SAP automatically sets a payment block on the invoice. This block prevents the vendor from being overpaid and requires a human to review the discrepancy. The three-way match is one of the most important financial controls in any company's accounts payable process.

The GR/IR (Goods Receipt / Invoice Receipt) account is a clearing account in SAP that bridges the gap between goods receipt in MM and invoice posting in FI. When goods arrive and a GR is posted, the inventory account is debited (stock increases) and the GR/IR account is credited - meaning "goods received, invoice expected." When the vendor's invoice arrives and is posted in MIRO, the GR/IR account is debited and the vendor account is credited - meaning "invoice received, this clears the pending GR." The GR/IR account acts as a temporary holding account. In a perfectly matched process, every debit to GR/IR from a GR is eventually matched and cleared by a credit from an MIRO posting. Uncleared items in the GR/IR account represent goods received but not yet invoiced, or invoices received for goods not yet delivered. T-code MB5S shows the GR/IR balance and helps identify uncleared items.

A movement type in SAP MM is a three-digit code that defines the type of stock movement - what kind of inventory transaction is happening and what accounting entries should be created automatically. Each movement type controls: which accounts are posted, in which direction (debit or credit), and which stock type is affected. Three important examples: Movement type 101 - Goods Receipt against a Purchase Order. Stock increases, GR/IR account is cleared. Used in MIGO when goods arrive from a vendor. Movement type 261 - Goods Issue to a Production Order. Stock decreases as raw material is consumed in manufacturing. Movement type 311 - Transfer Posting from one storage location to another within the same plant. Stock moves from raw material store to production area - no accounting entry, just inventory reorganisation. T-code OMJJ is used to configure movement types.

A posting period in SAP FI is a time interval - typically a calendar month - during which financial transactions can be posted. SAP prevents posting to closed periods to protect the integrity of already-reported financial statements. If a period is closed and you try to post a document with a date in that period, SAP gives error message F5 354: "Posting period [period] [year] is not open for account type [type] in company code [company code]." The posting period is controlled by T-code OB52 (Posting Period Variants) where the finance team opens and closes periods. Typically, the current period and one or two prior periods are kept open for corrections. When a period is closed it is locked from further postings to ensure that the financial reports for that period remain accurate and audit-ready. To fix the error, either post with a date in an open period or ask the finance team to temporarily open the closed period using OB52.

A Purchase Requisition (PR) is an internal document - it is a request from a department saying "we need to buy this." It does not commit the company to any purchase and is not sent to the vendor. It typically requires internal approval and can be converted to a PO once approved. T-code ME51N creates a PR. A Purchase Order (PO) is an external document - it is the formal legal commitment from the company to the vendor to buy specific goods or services at an agreed price and by a specific delivery date. The PO is sent to the vendor and creates a legal obligation on both sides. T-code ME21N creates a PO. In summary: the PR says "please buy this" internally, and the PO says "we are buying this" to the external vendor. A PO can be created directly without a PR (if the company allows it) or by converting an approved PR.

SAP FICO refers to the Financial Accounting (FI) and Controlling (CO) modules together - they are almost always implemented together and are considered one combined functional area. FI (Financial Accounting) deals with external financial reporting - it records all financial transactions in the General Ledger, produces the balance sheet and P&L for external stakeholders (banks, regulators, shareholders), and manages accounts payable, accounts receivable, and asset accounting. CO (Controlling) deals with internal management reporting - it tracks costs and revenues for internal decision-making, using cost centres, profit centres, internal orders, and product costing. The key difference: FI produces statutory financial statements for external reporting; CO produces management information for internal business decisions. A cost incurred in purchasing is an FI document (vendor payable) and a CO document (cost assigned to a cost centre) simultaneously - they are linked but serve different purposes.

The most important FI tables are: BKPF - Accounting Document Header. Stores one row per posted financial document - document number, company code, fiscal year, posting date, document type, reference, created by. BSEG - Accounting Document Line Item. Stores each line of a financial document - account, amount, debit/credit indicator, cost centre, assignment. Every BKPF entry has at least two BSEG entries (one debit, one credit). SKA1 - G/L Account Master (chart of accounts level). SKB1 - G/L Account Master (company code level). LFA1 - Vendor Master General Data. LFB1 - Vendor Master Company Code Data. KNA1 - Customer Master General Data. In S/4HANA, the main table is ACDOCA (Universal Journal) which consolidates data that was previously spread across multiple tables.

This is actually one of the most important questions in a fresher interview and most candidates answer it defensively. Do not be defensive. Turn it around: "You are right that I have not worked on a live SAP implementation yet - but I want to explain what I have done to prepare and why I believe I am ready to contribute quickly. I have studied the complete procure-to-pay process and can walk through each step from ME51N to F110. I understand the organisational structure - client, company code, plant, storage location. I have studied the key configuration transactions like OB52 for posting periods, and I understand why businesses use SAP as an integration platform rather than separate systems. The concepts I have learned are directly applicable to real work. What I bring that experience cannot give you is fresh energy, a willingness to learn any aspect of the project you need, and the commitment to invest fully in developing my SAP skills within this organisation."

Give a specific, realistic answer - not "I want to be a manager" which sounds generic. A good answer: "In 5 years I want to be a Senior SAP [module] Consultant with hands-on experience across at least two full implementation cycles. In the first two years I want to establish a strong foundation - getting certified in SAP [module], contributing to at least one live implementation, and developing confidence in both configuration and troubleshooting. By year three to four I want to be leading functional design workshops with business users, building business requirements documents, and mentoring junior consultants. By year five I want to be the go-to person for [module] issues within my team - someone clients and colleagues can trust with complex problems. I am also keen to build cross-module knowledge, particularly the integration between [your module] and FI, because consultants who understand integration are far more valuable than those who only know one module."

Be honest and specific here - do not just say "SAP is the best." A good answer: "SAP has the largest installed base globally - it is used by over 90% of Fortune 500 companies and a very large proportion of India's top companies. This means the job market for SAP skills is significantly larger and more stable than for other ERP platforms. Oracle ERP and Microsoft Dynamics are strong products but have a smaller market share, particularly in the manufacturing, pharmaceutical, and FMCG sectors in India where SAP dominates. From a learning perspective, SAP has the richest ecosystem - training resources, certifications, SAP Community, and a clear career path. I also found that SAP's module structure - particularly the integration between FI and MM that I have studied - maps very closely to how real businesses actually work, which made the learning process feel relevant rather than abstract."

ABAP stands for Advanced Business Application Programming. It is SAP's proprietary programming language, developed specifically for building business applications within the SAP environment. What makes ABAP different from general-purpose languages like Java or Python: ABAP is designed to work natively with SAP's data model - it has built-in constructs for reading SAP tables using OpenSQL (SELECT statements that work across any database SAP supports). ABAP programs run inside the SAP application server, not as standalone executables. ABAP has built-in support for SAP-specific concepts like internal tables, work areas, field symbols, and the SAP dictionary (SE11). ABAP is primarily a 4th-generation language - it is more declarative and closer to business logic than low-level languages. In modern SAP (S/4HANA), ABAP has evolved significantly with object-oriented ABAP (classes and interfaces), Core Data Services (CDS views) for data modelling, and RESTful Application Programming (RAP) for building Fiori apps.

A Function Module in SAP ABAP is a reusable block of code that can be called from any ABAP program, from any part of the SAP system. It is stored in a Function Group (SE37) and has a defined interface - importing parameters (inputs), exporting parameters (outputs), changing parameters (inputs that are also modified), tables parameters (for passing internal tables), and exceptions (for error handling). A Function Module can also be called remotely as an RFC (Remote Function Call) from other SAP systems or external applications. A subroutine (FORM/PERFORM) is a simpler construct - it is defined within the same program or an include, and is local to that program. The key differences: Function Modules are globally accessible across the entire SAP system; subroutines are program-local. Function Modules have a formal interface definition; subroutines pass parameters less formally. Function Modules can be RFCs; subroutines cannot. In modern ABAP development, methods in ABAP classes have largely replaced both - but function modules are still heavily used throughout SAP standard code.