SAP FICO Consultant interview questions and answers

The company code is the smallest unit with its own complete set of books, usually one legal entity, for which a balance sheet and profit and loss statement are produced. The chart of accounts is the list of GL accounts; several company codes can share one operating chart, and there are also group and country charts. The fiscal year variant defines the periods, for example April to March with 12 posting periods and 4 special periods, which is SAP's standard variant V3, common in India.

The controlling area is the CO unit for internal cost accounting. One or more company codes are assigned to it, and they must share the same operating chart of accounts and fiscal year variant. Above all of these sits the client.

The Universal Journal is the single line-item table ACDOCA, which holds the postings of the general ledger, controlling, asset accounting and the material ledger together. In ECC these lived in separate tables with their own totals, such as BSEG and FAGLFLEXT for FI, COEP for CO and ANEP for assets, and FI and CO had to be reconciled.

The practical changes: FI and CO always agree, because they share the same line item; cost elements are now GL accounts, created in FS00 with the account type for primary or secondary costs, so KA01 is no longer used; totals and index tables such as BSIS and BSIK are replaced by compatibility views; and reports read line items in real time. BSEG still holds the entry view of FI documents.

In S/4HANA, customers and suppliers are maintained through the Business Partner, transaction BP, which replaces XD01, XK01, FD01 and FK01. A business partner holds general data once, such as name, address, PAN and bank details, and gets a role for each use: FLCU00 for the FI customer (company code data such as the reconciliation account and payment terms), FLCU01 for sales data, FLVN00 for the FI supplier and FLVN01 for purchasing data.

Customer-vendor integration (CVI) keeps the classic customer and vendor tables in sync in the background. The configuration covers BP groupings, number ranges and their link to customer and vendor account groups. In a conversion from ECC, every customer and vendor must first become a business partner.

An asset is created in AS01 under an asset class, which supplies the balance sheet account through account determination, the screen layout and default depreciation terms. Each depreciation area, such as book depreciation under the Companies Act and a separate area for Income Tax Act depreciation, has its own depreciation key and useful life. An acquisition usually comes from a purchase order or a vendor invoice with the asset as the account assignment, and the asset explorer, AW01N, shows the values by area.

The depreciation run, AFAB, posts the planned depreciation for the period to the GL. In S/4HANA, new Asset Accounting is mandatory: all depreciation areas can post in real time, values sit in the Universal Journal, and parallel ledgers carry the different accounting principles.

Month-end: open the new period and close the old one in OB52 once postings are done; post accruals and provisions; run depreciation with AFAB; revalue open foreign currency items, such as vendor invoices in dollars, with FAGL_FCV; check and clear GR/IR; settle internal orders and WBS elements (KO88, CJ88); run CO assessments and distributions (KSU5, KSV5); and reconcile subledgers with the GL before reporting.

Year-end adds the balance carryforward, FAGLGVTR, which moves balance sheet balances to the new year and P&L balances to retained earnings; the fiscal year change and year-end close in Asset Accounting; and the special periods for audit adjustments. Mention that the exact order is agreed with the finance team in a closing calendar.

SPRO opens the IMG, the Implementation Guide: the tree of all customising activities, such as defining company codes, document types or tolerance groups. Most FICO customising is client-dependent, so you configure it in the development system's customising client, and the system records the changes in a customising request. Programs and other repository objects go into workbench requests instead.

You release the request in SE09 or SE10, and the Basis team imports it into the quality system for testing and then into production through STMS. Production is normally locked against direct changes. Some settings, such as opening posting periods and entering exchange rates, are maintained directly in production because they're day-to-day business data.

A field status group, set in a GL account's company code data, decides which fields are suppressed, required or optional when you post to that account: for example, making the cost centre required for an expense account, or hiding it for a bank account. The groups belong to a field status variant (OBC4), which is assigned to the company code (OBC5). Posting keys (OB41) also have their own field status.

When both apply, SAP combines them using the stricter rule. Required with optional gives required; suppressed with optional gives suppressed. If one says required and the other suppressed, that's a conflict and the posting gives an error, so the configuration has to be corrected.

There are three main kinds. Tolerance groups for employees (OBA4) set, per company code, the maximum amount per document, the maximum per open item for customers and vendors, the cash discount a user may give, and the payment differences they may accept; users are assigned to a group in OB57. GL account clearing tolerances (OBA0) allow small differences when clearing GL accounts. Customer and vendor tolerances (OBA3) control payment differences and residual items for the accounts assigned to each group.

So the clerk's group gets a lower amount per document, such as ₹5 lakh, and the accountant's group a higher one. To route larger invoices for approval instead of just blocking them, combine this with parking and a release workflow.

F110 pays vendors, and can collect from customers, in one run. You enter a run date and identification, then the parameters: company codes, payment methods, the next payment date and the vendor range. The proposal lists the items due, which you can edit or block; the payment run posts the payment documents and clears the invoices; and the printout step produces cheques or a payment file for the bank, usually through the Payment Medium Workbench with a DMEE format.

The configuration is in FBZP: all company codes, paying company codes, payment methods per country and per company code, bank determination (ranking order, bank accounts and available amounts) and value dates. In S/4HANA, house bank accounts are kept in Bank Account Management, through the Manage Bank Accounts app.

First test it yourself in the development system's unit-test client, posting real scenarios, not just checking that the settings saved. Then, once the transport is in the quality system, run integration tests with business users on the whole process, such as purchase order to goods receipt to invoice to payment, so you see the effect on MM and SD postings, plus negative tests, such as a posting that should be blocked.

Keep test scripts with the expected accounting entries, and record results for sign-off. Check the transports too: dependent requests must move in the right sequence, or production can end up with half the configuration. Regression-test related processes, because a change to account determination can affect postings you didn't touch.

At goods receipt against a purchase order (MIGO, movement type 101), SAP debits inventory (transaction key BSX) and credits GR/IR clearing (WRX) with the PO value. For a standard-price material, inventory is debited at the standard price and any difference goes to price differences (PRD). At invoice receipt (MIRO), it debits GR/IR, debits input GST and credits the vendor's reconciliation account; an invoice price different from the PO price goes to PRD for a standard-price material, or to inventory for a moving-average one if stock covers it.

The accounts come from OBYC, using the valuation grouping code, the material's valuation class from its accounting view, and the transaction key. GBB with modifiers such as VBR handles offsetting entries like goods issue to a cost centre.

When goods are issued for the delivery (post goods issue, movement type 601), SAP debits cost of goods sold, found in OBYC through GBB with modifier VAX, and credits inventory (BSX). When the billing document is released to accounting, it debits the customer, which posts to the customer's reconciliation account, and credits revenue and output GST. When the customer pays, the incoming payment, for example through F-28, clears the open item.

Revenue accounts come from VKOA, revenue account determination, which uses the condition technique: chart of accounts, sales organisation, the customer's and material's account assignment groups, and the account key from the pricing procedure, such as ERL for revenue, ERS for sales deductions and ERF for freight.

Check VFX3, the list of billing documents blocked for accounting, or open the document in VF02, and try to release it: SAP then shows the actual error. The usual causes: missing revenue account determination in VKOA, often because the customer or material has no account assignment group; a closed posting period in OB52; a GL account not created in that company code, or a field status requiring a field, such as a profit centre, that wasn't filled; a missing tax code or GST condition; or a billing type deliberately set to block automatic posting.

Fix the master data or configuration, release the document, then check whether similar documents are stuck. Mention that VFX3 should be part of the daily or month-end checks.

SAP Activate, used for S/4HANA projects, has six phases: Discover, Prepare, Explore, Realize, Deploy and Run. ASAP, the older method used for ECC projects, had five: Project Preparation, Business Blueprint, Realization, Final Preparation, and Go-Live and Support.

The main difference is how requirements are gathered. ASAP documented the business's processes in a detailed blueprint before building anything, which was thorough but slow. Activate starts from SAP's best-practice processes in a pre-configured system and runs fit-to-standard workshops in Explore, showing users the standard and recording only the real gaps in a backlog, then builds in short agile sprints in Realize. So Activate pushes clients towards standard processes.

Migrate master data first: GL accounts, business partners for customers and suppliers, cost centres, profit centres and fixed assets. Then migrate the transactional data at the cut-off date: open items for customers and suppliers, posted against migration clearing accounts rather than the real GL accounts; balances for GL accounts not managed by open items; and asset values with acquisition cost and accumulated depreciation.

In S/4HANA, the main tool is the Migration Cockpit, through the Migrate Your Data app (LTMC in older releases), using templates or staging tables. After each load, reconcile with the legacy trial balance, get finance's sign-off, and make sure the migration clearing accounts net to zero. Do at least two mock loads before the real cutover.

Cutover is the planned sequence from the old system to the new: stopping legacy postings, the final data loads and reconciliation, opening posting periods, checking number ranges, bank and payment set-up and user access, and then the go or no-go decision. It's rehearsed in mock cutovers and tracked hour by hour.

Hypercare is the first few weeks after go-live, when the project team supports users closely before handing over to the support team. Typical finance issues: missing authorisations, account determination gaps in scenarios that weren't tested, output forms, payment files rejected by the bank, and GST reports that don't match. The first month-end close is the real test, so plan to support it closely.

Each state's GST registration (GSTIN) is set up as a business place under the company code, with its GSTIN, and plants are assigned to the right business place so each transaction carries it. Tax is calculated with the condition-based tax procedure for India, TAXINN, using tax codes and condition records for CGST and SGST on supplies within a state and IGST on supplies between states, based on the supplying and receiving regions.

Separate GL accounts are kept for input and output CGST, SGST and IGST, so input tax credit and liabilities can be tracked. The business place on each document lets GSTR-1 and other returns be prepared per GSTIN. Mention e-invoicing and e-way bill integration, which are part of most Indian implementations.

Use document splitting, with segment, and usually profit centre, as the splitting characteristics. Segments are assigned to profit centres, so most postings inherit them. Document splitting then divides lines such as the vendor, customer and tax lines in proportion to the expense or revenue lines of the same document, so every line carries a segment, and with zero-balancing switched on each document balances per segment.

Configure the splitting method (usually SAP's standard 0000000012), item categories for GL accounts, and document types mapped to business transactions, then activate it for the company code. Design it before go-live: introducing it into a running system later is a separate project.

This is a standard requirement, so I'd use a validation, not custom code. In OB28, create a validation for the company code at the line-item call-up point, with a prerequisite that the cost centre equals the given one and a check that the reference field isn't blank, issuing an error message if it is. Validations use simple Boolean rules, and substitutions (OBBH) can fill fields automatically in the same way.

Custom code would be needed only if the rule can't be expressed this way, such as a check against data in another system, and then through a validation exit or a BAdI, not a modification. Record the decision in the fit-gap, and test both positive and negative cases.

For each business process, compare the client's requirement with what standard SAP does, ideally in fit-to-standard workshops with a demo, and classify it: a fit, a fit with configuration, a gap that a workaround or process change can close, or a real gap needing development. For each gap, record why it matters, how often it occurs and its business value.

Before agreeing to development, check the standard options: configuration, validations and substitutions, business transaction events, BAdIs, Fiori apps or SAP add-ons. If development is still needed, write a functional specification for it as a RICEFW object: report, interface, conversion, enhancement, form or workflow. Every custom object adds testing and upgrade effort, so challenge "we've always done it this way" politely.

Keep it to about a minute and connect your finance background to SAP. For example: "I'm a [B.Com, M.Com, MBA Finance or CA Inter] from [college]. I worked for [time] as an [accounts executive] at [company], handling vendor invoices, GST reconciliation and month-end entries, so I know the accounting behind FICO. I then trained in SAP FICO on S/4HANA, configuring a company code, GL, payables, receivables, asset accounting and cost centres, and ran procure-to-pay and order-to-cash end to end. I'm looking for a role where I can combine both."

Your accounting knowledge is your advantage, so lead with it.

Show that you understand what a consultant does: "In my accounts job I used SAP every day and became curious about why it posted entries the way it did. I enjoy understanding a process and setting it up so that hundreds of users get it right automatically. FICO lets me use my accounting knowledge on the design side: configuring the system, solving issues and working with different businesses. With so many companies moving to S/4HANA, there's a lot of that work ahead."

Avoid answering only about salary; say what you'll enjoy and what you'll contribute.

Answer honestly and show you know what project life involves: "Yes. I understand implementation projects need on-site workshops with the client, and that go-live, the first month-end and the year-end close are intense periods with long days. I'm comfortable with that, and I see it as the fastest way to learn."

If you have a limitation, such as being unable to relocate for a long period, say so clearly now and mention what you can do, such as frequent short trips. A clear answer is better than a yes you can't keep.

Show that you listen, look for standard options first and are clear about trade-offs: "I'd first understand what decision the report supports, because the layout often matters less than the figures. Then I'd show what standard reports and Fiori analytical apps can do, such as saved layouts, filters and export to Excel, which often covers most of it. If a real gap remains, I'd explain the options, such as a custom report or a CDS-based Fiori app, with the effort, cost and testing involved, and take it through the change request process."

Interviewers want to see that you neither say yes to everything nor brush off a senior user.

Structure it clearly: the client and industry, the project type (such as an S/4HANA greenfield implementation or an ECC conversion), the scope, your role, what you configured, one problem you solved, and the go-live. For example: "It was an S/4HANA implementation for a [manufacturing] company with [number] company codes. I handled accounts payable and asset accounting: I configured the payment program, tolerance groups and asset classes, wrote test scripts and supported the migration of open items. One issue was [problem], which I solved by [action]."

Be completely truthful: interviewers ask detailed follow-up questions on whatever you claim.