SAP FICO Interview Questions

FI is built for external stakeholders such as auditors and tax authorities and follows statutory rules, while CO is built for internal management to track costs and profitability. FI postings are legally required, CO postings support decision making.

A chart of accounts is the list of general ledger accounts used to record financial transactions in a company. It defines the account number range, account names, and whether an account is a balance sheet or P&L item.

A company code is the smallest organizational unit in SAP FI for which a complete set of financial statements can be produced. Every financial transaction is posted against a specific company code.

A fiscal year variant defines how many posting periods a fiscal year has and their start and end dates. SAP supports both calendar year variants and non-calendar variants with shifted periods.

A posting period is a time segment, usually a month, into which accounting transactions get recorded. Posting period variants control which periods are open or closed for each company code.

The general ledger is the central repository of all accounting entries in FI, providing a complete record of every business transaction. It is the source for balance sheets and profit and loss statements.

Accounts payable is the sub-ledger that manages a company's obligations to vendors, covering invoice entry, payment processing, and vendor master data. It updates the general ledger automatically through reconciliation accounts.

Accounts receivable is the sub-ledger that manages amounts customers owe a company, covering invoice posting, incoming payments, and dunning. Like AP, it links to the general ledger through reconciliation accounts.

A reconciliation account is a general ledger account linked to a sub-ledger, such as AP or AR, so that every sub-ledger posting is automatically reflected in the general ledger. You cannot post directly to a reconciliation account.

Asset accounting tracks fixed assets from acquisition through depreciation to retirement. It maintains asset master records, calculates depreciation, and posts values to the general ledger.

Depreciation is the systematic reduction of an asset's book value over its useful life, calculated automatically based on depreciation keys assigned to the asset. SAP supports methods like straight-line and declining balance.

A cost center is an organizational unit representing where costs are incurred, such as a department or a production line. Costs get assigned to cost centers for tracking and reporting purposes.

A profit center is an organizational unit used to evaluate the profitability of a part of a business, such as a product line or a region. Unlike a cost center, it tracks both costs and revenues.

An internal order is a tool for tracking costs and, in some cases, revenues for a specific short-term task or project, such as a marketing campaign or a repair job. It can later settle those costs to a cost center or asset.

A cost center is a permanent organizational structure used for ongoing cost tracking, while an internal order is typically temporary and tied to a specific project or event. Internal orders can settle their costs to cost centers.

A vendor master record stores all information SAP needs to conduct business with a supplier, including address, bank details, payment terms, and the reconciliation account. It is shared across FI and materials management.

A customer master record stores information about a buyer, including address, payment terms, credit limit, and the linked reconciliation account. It supports both FI and sales processes.

A document type is a two-character key that classifies the kind of accounting document being posted, such as vendor invoice or customer payment. It controls the number range and which account types can be used.

A posting key is a two-digit code that determines the account type being posted to, such as debit or credit, and whether the line item is for a customer, vendor, or general ledger account. Common examples are 40 for a GL debit and 50 for a GL credit.

An account group controls the number range and the screen layout, meaning which fields are required, optional, or hidden, when creating a general ledger account. It groups similar accounts together for consistent maintenance.

A controlling area is the organizational unit in CO within which cost accounting is carried out consistently. One controlling area can span multiple company codes if they share the same operational chart of accounts.

The operating chart of accounts is the chart of accounts used for both FI and CO postings within a controlling area, ensuring cost elements align directly with GL accounts. It is the mandatory chart assigned to a company code.

A primary cost element is a cost element that corresponds directly to a P&L general ledger account, created so that expenses can flow from FI into CO for cost tracking. Every relevant expense account needs one.

A secondary cost element exists only in CO, used for internal allocations like assessments and settlements that have no direct FI counterpart. It never appears on a financial statement.

The New General Ledger, introduced in SAP ECC 6.0, combines classic FI with elements previously handled separately, such as profit center accounting, into one ledger with document splitting support. It reduces the need for separate reconciliation.

Document splitting is a New GL feature that automatically splits accounting line items, such as a vendor invoice, so each line carries the correct dimension like profit center or segment. It ensures balanced financial statements per dimension.

The standard sub-modules are general ledger accounting, accounts payable, accounts receivable, asset accounting, bank accounting, and travel management. Each sub-ledger feeds the general ledger.

The goods receipt/invoice receipt clearing account temporarily holds the value of goods received but not yet invoiced, or invoiced but not yet received. It gets cleared automatically once both documents match.

The trial balance lists the debit and credit balances of all general ledger accounts at a point in time, used to confirm that total debits equal total credits before closing. It is the starting point for financial statement preparation.

A dunning procedure is an automated process that reminds customers about overdue payments through a series of escalating dunning letters. It is configured with levels, intervals, and minimum amounts.

The automatic payment program, transaction F110, processes outgoing payments to vendors, such as check runs or bank transfers, by selecting open items based on defined payment methods and due dates. It reduces manual payment posting.

A tax code is a two-character key that determines the tax percentage rate and the general ledger account to which tax amounts post during a transaction. It is assigned per country and tax procedure.

Withholding tax is tax deducted at source on a vendor payment, remitted directly to the tax authority on the vendor's behalf. SAP supports both classic and extended withholding tax configurations.

Real-time integration posts CO postings, like cross cost center allocations, to FI immediately as they occur, while periodic reconciliation runs a batch job at period end to true up the two. Real-time integration reduces closing time.

A special GL indicator marks transactions like down payments, guarantees, or bills of exchange that need to post to a different reconciliation account than the normal customer or vendor account, while still linking to that business partner.

I would reverse the CO document if the FI posting was correct, using a repost of costs (KB61) or a manual reclassification, rather than reversing the FI invoice itself. If the invoice was also posted to the wrong GL account, I would correct that with a proper reversal and re-entry.

I would run the GR/IR analysis report to identify line items where goods receipt and invoice receipt quantities or values do not match, then work with procurement to confirm whether goods were actually received. Stale items often need manual clearing after confirming with the business.

I would map valuation classes to general ledger accounts through the OBYC transaction, working closely with the MM team to confirm the movement types in play. Getting the account modifier and transaction key combinations right up front avoids postings landing in generic clearing accounts.

I would run recurring entries and accruals first, then depreciation posting, foreign currency valuation, and cost allocations like assessments and distributions. After that I would reconcile CO to FI, run the trial balance, and lock the posting period.

I would structure it by function first, such as production, maintenance, and administration, then break production down by plant or line. Keeping the hierarchy aligned with how management actually reviews reports avoids rework later.

I would review the customer's credit limit and payment history in FSCM or classic credit management, then decide whether to place a credit block that requires manual release. For high-value accounts I would also check the dunning history and open item aging.

I would run the foreign currency valuation program against open items and GL balances in foreign currency, using the exchange rate type set up for valuation. The resulting unrealized gain or loss posts to a dedicated account and reverses automatically at the start of the next period.

I would confirm both company codes are using the same intercompany clearing accounts and trading partner fields are populated correctly on every posting. Running the intercompany reconciliation report regularly, rather than only at period end, catches mismatches early.

I would check the asset's depreciation key, useful life, and capitalization date first, since a wrong start date is the most common cause. I would also confirm whether a manual depreciation adjustment or an asset value correction was posted outside the standard run.

I would create the asset class with its own account determination and screen layout, then link appropriate depreciation areas, for example one for book depreciation and one for tax. I would coordinate with the business to confirm the useful life and depreciation method that match the lease terms.

I would map legacy GL accounts to the new universal journal structure, checking that account types like balance sheet versus P&L are preserved. I would also confirm cost elements and GL accounts are unified correctly since S/4HANA merges them into one object.

I would trace the document split rule that generated the entry and confirm the default profit center derivation on the relevant cost objects. Often the fix is correcting a substitution rule or adding a default assignment for a cost center that was missing one.

I would create a separate dunning procedure with its own levels and intervals tailored to that segment, then assign it at the customer master level. I would also review minimum amounts so small balances don't trigger unnecessary dunning letters.

I would check the vendor's payment block, payment method, and house bank assignment first, since those are the most common causes. I would also confirm the invoice due date falls within the payment run's date selection parameters.

I would define the required characteristics and value fields in the operating concern, then confirm the relevant condition types and cost components flow into those value fields from sales and costing. Testing with a sample sales order before go-live catches mapping gaps early.

I would run the final depreciation posting for the year, execute the fiscal year change program, and confirm all planned asset transactions like retirements are complete. I would then reconcile the asset history sheet against the general ledger balance.

I would review the assessment or distribution cycle's sender and receiver rules to check for overlapping cost center ranges. A common cause is a cycle segment that includes a cost center that already received an allocation in an earlier segment of the same cycle.

I would define clearing criteria, such as assignment number or reference, in the automatic clearing program configuration, then schedule it to run after key transactions post. I would test it on a copy of production data first since incorrect criteria can clear items that shouldn't match.

I would check the account determination procedure in SD, specifically the condition technique mapping condition types to GL accounts, since most SD-FI posting failures trace back there. I would also confirm the billing document's pricing procedure matches what was configured for that sales area.

I would create a validation using transaction GGB0 that checks the account type against the cost element and rejects the document if the cost center field is blank. I would scope the rule narrowly to relevant document types to avoid blocking unrelated postings.

I would verify whether the retirement was processed with revenue, using the correct transaction type, since a retirement without revenue zeroes out the asset differently than a sale. I would also check that the gain or loss account is configured correctly in account determination.

I would check that every internal order has a settlement rule pointing to a valid receiver, such as a cost center or asset under construction, before running the settlement. Orders without a rule cause the settlement run to error out and delay closing.

I would compare the electronic bank statement against open items in the bank clearing accounts, checking whether the posting rules in the bank statement configuration are matching on the correct criteria like check number or reference. Manual research is usually needed for items that don't auto-clear.

I would map every closing activity to its execution time and dependencies, looking for serial steps that could run in parallel, such as depreciation runs across different company codes. Cost allocation cycles and foreign currency valuation are common bottlenecks worth reviewing for batch job scheduling.

I would standardize intercompany clearing accounts and trading partner assignment rules across all company codes first, since inconsistent setup is the biggest cause of reconciliation pain at scale. I would then evaluate a dedicated tool, whether SAP's intercompany reconciliation or a third party, rather than relying on manual spreadsheet matching.

I would assess how deeply the current setup relies on classic depreciation areas and parallel ledgers, since the new asset accounting model changes how depreciation areas post to the ledger. I would run a data consistency check on asset history sheets before migration since discrepancies there cause conversion errors.

I would keep a core set of shared characteristics and value fields at the operating concern level, then use derivation rules to populate unit-specific dimensions rather than creating separate operating concerns. That keeps consolidated reporting possible while still letting each unit slice data its own way.

I would push more validations and automatic postings, like recurring entries and standard accruals, earlier in the month rather than batching everything at close. I would also look at which manual journal entries are recurring in nature and could become templates or workflow-approved automated postings.

I would review the authorization roles tied to F-58 and F110 and separate vendor master maintenance, invoice posting, and payment release into distinct roles. I would also recommend a workflow-based payment release step for amounts above a threshold as a compensating control.

I would centralize reconciliation account and clearing account logic so shared services can process transactions consistently regardless of which company code they're working, while keeping company-code-specific tax and statutory accounts separate. This keeps the shared team's processes uniform without breaking local compliance.

I would check whether the exchange rate type used for valuation matches what auditors expect for period-end rates, and confirm the valuation method, lowest value versus always valuate, is applied consistently. I would also verify that valuation is running against the correct set of open items and not double valuing items already cleared.

Document splitting gives balanced financial statements by profit center or segment automatically, which matters a lot for companies needing segment reporting, but it adds configuration complexity and can complicate custom postings. For a company without strict segment reporting needs, classic GL with periodic reconciliation might be simpler to maintain.

I would build allocation cycles referencing cost center groups rather than individual cost centers, so group membership changes propagate automatically without editing every cycle. I would also schedule a periodic review of group definitions against the current org structure.

I would standardize settlement profiles and default settlement rules at the order type level so departments can't skip settlement or send costs to inconsistent receivers. I would also build a report to catch orders sitting open past their expected close date.

I would prioritize aligning the chart of accounts and controlling area structure first since those are hardest to change later, while accepting temporary differences in less critical configuration like dunning procedures. I would set a realistic multi-year roadmap rather than forcing a single cutover that risks business disruption.

Centralization drives consistency and lower transaction cost per invoice, but it can slow down entities with unique statutory or language requirements that need local expertise. I would look at transaction volume and regulatory complexity by region to decide which processes centralize well and which need to stay local.

I would set clear thresholds, such as project duration or budget size, that determine when a lightweight internal order is sufficient versus when a full project system WBS structure is warranted. Without that policy, teams tend to default to whichever tool they know, leading to inconsistent project reporting.

I would quantify the closing time reduction from the universal journal's real-time GL and CO reconciliation, since that alone often justifies a large share of the investment. I would also weigh the one-time cost of remediating custom code and reports built against classic FI-CO tables.

I would require a formal intake process with finance business partner sign-off before creating new cost objects, since uncontrolled proliferation makes reporting and allocation cycles harder to maintain over time. I would pair that with a periodic cleanup review to retire unused objects.

I would start with the highest-volume, most predictable recurring postings, since automating those yields the fastest close-time payoff with the lowest risk. I would leave judgment-heavy accruals manual but templated, so reviewers can still apply discretion where estimates genuinely vary period to period.

I would use parallel ledgers within the New GL or universal journal rather than separate accounts for each standard, since that keeps a single source of truth with valuation differences isolated to specific ledger postings. I would document clearly which transactions need ledger-specific treatment so business users understand the reporting differences.

I would assess whether SAP's workflow and approval configuration can enforce controls regardless of who is keying transactions, since the risk isn't really about who processes it but whether the system enforces segregation of duties and audit trails. I would also weigh the transition cost against expected savings over a multi-year horizon.

I would define mandatory field completeness rules enforced at creation, tie master data changes to an approval workflow, and schedule periodic duplicate-vendor detection reports. Poor master data quality tends to cause more downstream FICO issues than configuration problems do.

I would calculate the current manual effort spent reconciling intercompany balances and compare it against the tool's license and implementation cost, factoring in how much faster close becomes. For organizations with high intercompany transaction volume across many entities, the payback period is usually short.

I would balance statutory retention requirements, which vary by country, against system performance, archiving detailed transaction history for older fiscal years while keeping summarized balances readily accessible. I would involve tax and legal early since retention requirements differ meaningfully across jurisdictions.

I would set a global baseline policy but allow regional variance in dunning intervals and credit thresholds where local business practice genuinely differs, documenting the exceptions centrally so finance leadership retains visibility. A one-size approach usually causes friction with sales in markets with different payment cultures.

I would review recent business decisions that needed profitability data and check whether the current CO-PA characteristics could actually answer those questions, since granularity gaps often only surface when leadership asks a question the model wasn't built for. I would prioritize adding characteristics tied to recurring strategic questions rather than trying to capture everything up front.

I would start by documenting current-state configuration and known pain points across business units, then establish a standard change process so future enhancements go through consistent design review. I would staff the center with a mix of functional and technical skill so configuration changes and custom development stay coordinated.

I would break the roadmap into phases that each deliver a measurable outcome, like reduced close time or fewer manual journal entries, rather than presenting one large multi-year initiative with value only at the end. Framing early wins in terms the CFO already tracks makes the longer-term investment easier to sustain.

I would invest early in reusable accelerators, like pre-built configuration templates and testing scripts, so new team members can ramp faster without relearning fundamentals project by project. I would also build a rotation between senior and junior consultants so knowledge doesn't concentrate in a small number of people.

I try to reframe the disagreement around the business outcome both sides actually want, like faster close or better audit readiness, since architecture debates often stall when framed only in technical terms. Bringing concrete tradeoffs, timeline versus flexibility for example, to a joint decision usually breaks the deadlock faster than either side unilaterally deciding.

I would prioritize training internal power users on configuration basics and troubleshooting during the implementation itself, beyond just go-live, so knowledge transfer happens continuously. I would also document design decisions with the business rationale attached, beyond just the technical steps, so future teams understand why choices were made.

I lay out the long-term maintenance cost of a workaround clearly, including who will need to support it after go-live, and let the client make an informed decision rather than unilaterally refusing. Sometimes the business context justifies deviating from standard practice, and my job is to make sure that decision is made with full visibility into the tradeoff.

I would identify consultants who already show strength in both technical depth and client communication, then deliberately expose them to program-level decisions, beyond just configuration tasks, well before a transition is needed. Giving them ownership of smaller initiatives first builds judgment that's hard to teach directly.

I would run regular knowledge-sharing sessions on what's changing structurally, like the universal journal replacing separate FI and CO tables, so the team doesn't keep designing around outdated assumptions. I would also pilot new capabilities on a smaller project before mandating them broadly across the practice.

I would present the delay with a clear root cause, the realistic revised timeline, and the specific decisions needed from leadership to get back on track, rather than a vague status update. Executives generally respond better to a direct account with a path forward than to a status report that avoids the hard news.

I set a standard that every significant configuration decision includes the business reason, beyond just the technical setting, since auditors and future team members both need that context long after the original team has moved on. I periodically sample documentation across modules to catch gaps before they become audit findings.

I would quantify the manual effort currently spent on repetitive tasks, like reconciliation or journal entry preparation, and compare that against the automation investment, factoring in error reduction as well as time saved. Leadership responds best when the case ties directly to metrics they already track, like close cycle time or audit finding counts.

I try to involve regional teams early in defining the standard rather than presenting a finished template, since resistance usually comes from feeling standards were imposed without accounting for real local needs. Building in a documented exception process for genuine statutory differences also reduces pushback significantly.

I would push the practice toward designing for real-time data flows from the start of any new implementation, rather than defaulting to legacy batch patterns out of habit, since client expectations have shifted meaningfully in that direction. I would also invest in the team's skills around the universal journal and embedded analytics rather than only classic reporting tools.