SAP FICO Interview Questions

"The client is the top level, a whole self-contained SAP environment with its own master data and most of its configuration. A company code is the smallest unit that produces a complete set of books for external reporting, so a balance sheet and a P&L, and it's usually one per legal entity. A controlling area is the unit for internal cost accounting. Several company codes can be assigned to one controlling area, which lets me allocate costs across them, but only if they use the same operational chart of accounts and the same fiscal year variant. One company code can belong to only one controlling area. On a project I'd settle this early, because merging or splitting controlling areas after go-live is painful. So the client holds everything, company codes carry the legal books, and the controlling area ties them together for management reporting."

"The operating chart is the one people actually post to. It's assigned to the company code, and every GL account has two parts: the chart-of-accounts part with the number, the name and whether it's a balance sheet or P&L account, and the company-code part with things like the account currency, open item management and the field status group. If a country needs its own legal numbering, I set up a country chart and put the matching number in the alternative account number field of the company-code part. Local reports can then come out in the local numbering while users still post to the operating accounts. For group reporting, the group account number in the chart-of-accounts part maps each account to the group chart, which consolidation reads. That way company codes in different countries can share one operating chart and still meet both local and group needs."

"The fiscal year variant tells SAP how a posting date turns into a period. Most setups have 12 normal periods and up to 4 special periods, so 16 at most. It can follow the calendar year, like K4, or a shifted year such as April to March, and it's year-dependent only if the period dates change from year to year. I assign it to the company code. Special periods are for year-end adjustments like audit entries: the posting date stays in the last normal period and I enter the special period. To control which periods are open I use OB52. There's a plus row that covers all account types, and I can add rows for assets, customers, vendors, materials and GL accounts, even account ranges, each with its own open periods. At month end I close the old period for most account types while leaving GL open a little longer so finance can finish adjustments."

"Every FI document has a document type, which works like its label. It decides which number range the document takes its number from, which account types are allowed on it, which document type is used when it's reversed, and whether fields like the reference are required. The ones I use daily are SA for general postings, KR for vendor invoices, KZ for vendor payments, DR and DZ for customer invoices and payments, and AA for asset postings. Document types are defined in OBA7. Number ranges are set in FBN1 per company code, and each interval is valid either for one fiscal year or, if I enter 9999 as the year, across years. Most ranges use internal numbering, where SAP assigns the next number, while external numbering suits documents that arrive with their own number from another system."

"I'd first get the exact message and the document the user was posting, because the details matter. If it's an FI posting, I'd open OB52 for the variant assigned to that company code and check every account type on the document. A vendor invoice needs the period open for vendors and for the GL lines, and for materials if stock is involved, not only the plus row. Often GL is open but vendors or assets were closed earlier as a close step. I'd also check that the posting date really falls in the period they think, since a shifted fiscal year can surprise people. If the error came from a goods receipt or issue, it's about the materials management period, which is opened separately, so I'd check that with the MM team. Once I know the gap, I'd open only what's needed, with approval from the close owner, and make sure it's closed again on time."

"A posting key is a two-digit code on each line that tells SAP whether it's a debit or a credit, what kind of account it hits, and which fields to show. So 40 is a GL debit and 50 a GL credit, 01 is a customer invoice and 11 a customer credit memo, 31 is a vendor invoice and 21 a vendor credit memo. Field control comes from two places. One is the posting key's own field status. The other is the account: the company code has a field status variant, and the GL account's field status group points to a set of rules inside it, for example cost center required on expense accounts. SAP combines both. If one says required and the other optional, it's required. If one says suppressed and the other optional, it's hidden. If one says required and the other suppressed, that's a config conflict and the posting fails."

"A reconciliation account ties a subledger to the GL. In the company-code part of the GL account I flag it as a reconciliation account for customers, vendors or assets, and each customer or vendor master record points to one. When I post a vendor invoice, the vendor line lands in the subledger and the same amount hits the reconciliation account at the same moment, so the two always agree, and nobody can post to it directly. Open item management is a different idea. Each line stays open until something clears it. I switch it on for accounts that should net to zero over time, like GR/IR, bank clearing and salaries payable, so I can see exactly which items are still waiting. I don't use it on reconciliation accounts, because the subledger already tracks open items, or on revenue and expense accounts. It's worth getting right at the start, because switching it on later needs a special conversion."

"Holding is like saving a draft. If I'm halfway through an entry and get pulled away, I hold it under a name I choose. It has no document number, SAP doesn't check it's complete, and I pick it up later. Parking is more formal. The document gets a number and is stored, but it doesn't touch the balances. Someone else can review it, change it and then post it, so it's the usual route for invoices that need approval, often with a workflow on top. A clerk parks the invoice, a manager checks it and posts it. Posting is the real thing: the GL and the subledger are updated and the document becomes part of the books. After that I can only change a few fields like the text or a payment block, and any real correction means a reversal or a new entry."

"Without splitting, only the expense or revenue lines carry a profit center or segment. The vendor line, the tax line and later the payment have none, so I can't draw a balanced balance sheet per segment. Document splitting fixes that. If a vendor invoice has two expense lines, one for profit center A and one for B, SAP splits the vendor and tax lines in the same ratio, and when the invoice is paid the payment follows that split too. To set it up I choose a splitting method, assign item categories to GL accounts, like vendor or expense, map document types to business transactions, pick the characteristics such as profit center and segment, and mark which must balance to zero, which needs a zero-balance clearing account. I also switch on inheritance and a default assignment so nothing ends up blank. Switching it on in a live system is a project of its own, so it's a day-one decision."

"I'd normally use the ledger approach. The leading ledger, 0L, carries the standard the group reports in, and I add a non-leading ledger for the other one. Most postings, like invoices and payments, go to every ledger automatically. Where the rules differ, say a provision or a valuation, I post to only one ledger using a ledger group. In asset accounting I map each depreciation area to its ledger, so each standard gets its own useful life and depreciation. The alternative is the accounts approach: one ledger with extra accounts for the differences, and reports that include or leave out certain accounts. It's simpler to start but gets messy as differences grow. In S/4HANA there's also the extension ledger, which stores only the adjustment postings on top of a base ledger, handy for management views without doubling every line. Either way, it's a decision for design time."

"I use FB60 for invoices that don't come from a purchase order, like rent, utilities or a one-off consultant bill. The clerk enters the vendor, the amount and the tax, and codes the expense line to a GL account and a cost center or order. MIRO is for invoices that follow a purchase order. It proposes the PO lines and the quantities already received, so it's a three-way match between what we ordered, what arrived and what was billed. The posting debits the GR/IR clearing account and credits the vendor, which offsets the credit the goods receipt made. If the price or quantity differs by more than the tolerance allows, SAP still posts the invoice but blocks it for payment, and purchasing or AP releases it once it's sorted, for example in MRBR. So FB60 is purely a finance posting, while MIRO sits on top of the logistics flow."

"When we pay a supplier in advance, that money isn't a normal payable, it's an asset, so it shouldn't net against the payables balance. SAP handles it with a special GL indicator, which sends the line to an alternative reconciliation account instead of the vendor's normal one. The flow starts with a down payment request in F-47. That's only a noted item, so balances don't change, but the payment program can pick it up. The payment itself goes through F-48 or F110 and posts with indicator A to the down payment account. When the final invoice arrives it's posted normally, and then I clear the down payment against it in F-54, which takes the advance off the asset account and reduces what we still owe. Customers work the same way in mirror image. The link between each special GL indicator and its alternative account is set per reconciliation account in config."

"In F-28, if a customer pays part of an invoice I have two choices. With a partial payment, the original invoice stays open for the full amount and the payment is posted as its own open item that points to it. It's clear what the original invoice was, but the account shows two open lines. With a residual payment, the invoice is cleared and SAP creates one new open item for what's still owed, so the account looks cleaner, though the link to the original invoice is weaker. For small gaps, like bank charges or rounding, tolerance groups decide what SAP can absorb. If the difference is within both the customer's and the clerk's tolerance, it posts automatically to a payment difference or cash discount account. Reason codes let me send, say, a short payment for damaged goods to a separate account or keep it open as a disputed item."

"The config sits in FBZP. First, all company codes, where I say which company code pays for which and set cash discount rules. Then paying company codes, with minimum amounts and forms. Then payment methods per country, like bank transfer or check, with the master data they need and the file format, and payment methods per company code with amount limits. Last is bank determination: the ranking order of house banks, the accounts, available amounts and value dates. On the master data side, the vendor or the invoice itself needs a payment method, bank details for transfers, and no payment block. To run it in F110 I enter a run date and an identification, then the company codes, payment methods, next payment date and vendors. I create the proposal, review it and fix exceptions, run the payment, which clears the invoices, and then create the payment medium, like the bank file."

"First I'd tell the supplier we're looking into it today, then open the run in F110 and check the exception list and the log, because SAP records why an item wasn't paid. The usual reasons are a payment block on the invoice or the vendor, an invoice that isn't due before the next payment date so the program waits, a missing payment method or bank details, an amount outside the limits for that payment method, or no house bank with enough available amount. Sometimes the item was locked by another proposal running at the same time. Once I know the cause, I fix it properly: remove the block if it's approved, add bank details through the normal controls, or correct the terms only if the contract allows it. Then I pay through a small follow-up run or a manual payment, and give the supplier a date."

"The asset class is the template. Machines, vehicles and computers are separate classes, and each brings defaults: the account determination that says which GL accounts get the cost, the accumulated depreciation and the expense, plus the number range, the screen layout and default useful lives. The chart of depreciation is usually built per country, because depreciation rules differ, and it's assigned to the company code. Inside it are depreciation areas. Area 01 is normally the book area that posts to the GL, and others can hold tax or another accounting standard, each with its own useful life and method. The depreciation key on each area says how to calculate, straight-line or declining balance, and the period control, like whether an asset bought mid-month starts depreciating that month or the next. So when I create an asset, the class fills in the defaults and I only adjust what's different."

"An asset usually comes in through purchasing. The PO line has the asset as its account assignment, so the goods receipt or the invoice capitalises it straight onto the asset. Without a PO, I can post the vendor invoice against the asset in F-90. For something built over months, costs collect on an asset under construction and I settle it to the final asset when it's ready. Once capitalised, the asset explorer, AW01N, shows the planned depreciation for each area, and the monthly run, AFAB, posts it to the GL. I always do a test run first. If an asset moves to another cost center or gets split, I use a transfer. When it's sold, I post a retirement with revenue, for example F-92 when there's a customer, and SAP works out the net book value and posts the gain or loss. If it's simply scrapped, ABAVN writes off the remaining value."

"A cost center answers where money is spent. It's usually a department, like HR, IT or a maintenance team, and managers are measured on whether they stay within plan. Every cost center sits in the standard hierarchy of the controlling area. A profit center answers which part of the business makes money. It might be a product line or a region, it gets revenue and costs, and it can carry balance sheet items too, so management can see a P&L for it. Each cost center is assigned to one profit center, which is how its costs flow up. An internal order is for something temporary, like a trade fair or a one-off repair. I post the costs to the order to track them separately, then settle them at month end to a cost center, an asset or another receiver. If I only want to track costs without moving them, a statistical order does that while the real cost stays on the cost center."

"Both are periodic allocations set up as cycles with segments. Each segment has sender cost centers, receivers and a tracing factor, like fixed portions, fixed amounts or a statistical key figure such as headcount or floor space. The difference is what the receiver sees. Distribution moves only primary costs and keeps the original cost element, so if the facilities cost center sends out electricity and rent, the receiver sees electricity and rent. Assessment can move primary and secondary costs, but it posts everything under one secondary cost element of the assessment type, so the receiver sees a single line like facilities charge. I use distribution when the receiving manager needs the detail, and assessment when a summary is enough or when I need to pass on costs that were themselves allocated. Assessment runs in KSU5 and distribution in KSV5, and I always do a test run before the real one."

"Most of it hangs off the order type. The settlement profile says which receivers are allowed, like a cost center, an asset or a GL account, and points to an allocation structure that maps the order's cost elements to a settlement cost element. On each order I enter a settlement rule, for example all costs to one cost center, or a split across two. At month end I settle one order in KO88 or many in KO8G, with a test run first. For budgets, the order type has a budget profile. I enter the budget on the order, and if availability control is active, SAP checks each posting against it. The tolerances work in levels, like a warning when spending gets close to the budget and an error once it's over, which stops the posting. A statistical order can't be settled, because the real cost already sits on the cost center, so settlement only applies to real orders."

"When I post a goods receipt with movement type 101, SAP works out the entries from the movement type and the material. The material's accounting view has a valuation class, the plant's valuation area has a valuation grouping code, and the movement type brings the transaction keys. In OBYC each key maps those inputs to a GL account. For a stock item, BSX gives the inventory account and WRX gives GR/IR clearing, so the receipt debits inventory and credits GR/IR. If the material uses standard price and the PO price differs, the gap goes to the price difference account from PRD. GBB is the offsetting key for other movements and uses modifiers, like VBR when I issue stock to a cost center, which debits consumption and credits inventory. When an error says account determination isn't possible, I check the valuation class, then the grouping code, then the OBYC entry, and I can simulate it to see which key failed."

"Revenue account determination uses condition technique. In the pricing procedure each condition carries an account key, like ERL for revenue or ERS for discounts. When the billing document is released to accounting, SAP searches VKOA with the chart of accounts, the sales organisation, the customer's account assignment group from its sales area data, the material's account assignment group from its sales view, and the account key. The access sequence decides which combination is tried first, so I can have a general rule plus exceptions. The posting debits the customer, which hits its reconciliation account, and credits revenue and output tax. The tax account doesn't come from VKOA, it comes from the tax setup in FI. Before all that, at goods issue for the delivery, the inventory side posts: debit cost of goods sold and credit inventory, and that uses OBYC on the MM side, not VKOA."

"I'd start with VFX3, which lists billing documents not yet passed to accounting, and I'd try releasing one so I can read the exact message. The most common cause is revenue account determination: a new material or customer has an account assignment group with no entry in VKOA, so there's no revenue account to post to. Other things I'd check are a closed posting period, a customer with no company code data or reconciliation account, a missing profit center, or a tax code problem. Once I find the cause I fix it at the source, for example add the VKOA entry for that combination, then release the documents again. After that I'd check the customer line items to confirm they're showing as due, and let sales know. If it came from new master data, I'd ask the master data team to add that field check to their creation checklist so it doesn't come back."

"I start by opening the new period, both FI in OB52 and the materials period, so operations isn't blocked. Then the posting work: recurring entries, accruals that reverse on the first day of next month, and the depreciation run. Next is cleanup and valuation. I look at GR/IR for items received but not invoiced and the other way round, revalue open foreign currency items, and reconcile bank and intercompany accounts. Controlling comes after FI, because allocations need the final costs, so I run distributions and assessments in the right order, then settle internal orders. Once CO is done I lock the CO period so nothing more lands there, then close the old FI period for most account types and leave GL open briefly for last adjustments. Finally I check the trial balance and run the balance sheet and P&L. In S/4HANA there's no separate FI-CO reconciliation step, because it's one journal."

"At period end, open items in a foreign currency, like a vendor invoice billed in another currency, and balances of accounts kept in a foreign currency, like a foreign bank account, are revalued at the closing rate. In S/4HANA that's FAGL_FCV. The difference between the booked amount and the new value posts as an unrealized gain or loss, with the accounts set up in OBA1. For open items the valuation is normally reversed on the first day of the next period. That matters, because when the invoice is finally paid, SAP calculates the realized gain or loss against the rate on the original posting. If the unrealized entry stayed in the books, the same difference would be counted twice. A foreign bank balance is different, since nothing clears it item by item, so that valuation usually stays and next month's run adjusts it. Before running, I check the key-date rates are loaded and do a test run."

"In ECC, finance data was spread over many tables. FI line items, GL totals, CO line items, asset values and the index tables for open and cleared items all lived separately, and a lot of close effort went into making them agree. In S/4HANA the Universal Journal, table ACDOCA, holds one line per posting with every dimension on it: GL account, cost center, profit center, segment, functional area, asset and more. Controlling, asset accounting and the material ledger all post into it. Cost elements are no longer a separate master: a primary cost element is simply a GL account of that type, and secondary cost elements are GL accounts too, created in FS00. Because there's one source, FI and CO can't drift apart, so the reconciliation ledger is gone and totals are calculated when needed. The old totals and index tables survive as compatibility views, so most older custom reports keep working."

"In S/4HANA I don't create vendors in XK01 or customers in XD01 any more, those take me to the BP transaction. A Business Partner holds the general data once, name, address, tax numbers, bank details, and then I add roles. For a supplier that's the FI vendor role, FLVN00, with company code data like the reconciliation account and payment terms, and FLVN01 for purchasing data. For a customer it's FLCU00 for finance and FLCU01 for sales. The same BP can carry both customer and supplier roles, which helps when we buy from and sell to the same company. Underneath, customer and vendor records still exist, and Customer Vendor Integration, CVI, keeps them in sync with the BP. On a conversion project CVI is a prerequisite: every customer and vendor must be synchronised to a BP before the technical conversion, so we clean data, align number ranges and groupings, and fix errors early."

"At my last company, on the second day of close, the trial balance showed a large balance on the GR/IR account that nobody could explain. I pulled the open items and sorted them by purchase order, and most came from one plant. The goods receipts had posted, but the invoices were sitting parked, because a new approver hadn't been added to the workflow after a reorganisation. So the config was fine, the invoices simply weren't posted. I worked with the AP lead to get them approved that day, which cleared most of the balance, and we posted an accrual for the rest that reversed on day one of the next month. Afterwards I added a check for parked invoices older than a week to our close checklist, and asked the workflow team for an alert when an approver slot is empty. At the next close that account was clean by day one."

"On an S/4HANA implementation at my last company I owned asset accounting for three company codes. The business needed local tax depreciation next to group book depreciation, so I designed the chart of depreciation with separate areas mapped to the leading and a non-leading ledger. I wrote the design, walked finance through it using their own machines as examples, and built the asset classes and account determination. Testing was where the value was. In integration testing we found asset purchase orders landing in the wrong class, because buyers were creating assets from an old template, so we fixed the process and added a check. For cutover I planned the legacy asset load, reconciled net book values against the old system asset by asset, and got finance to sign off. The first depreciation run after go-live matched exactly, and the lesson I kept was to test with real data early."

"A controller asked me for a custom report that would pull every cost center's actuals, regroup them into her own categories and reach her every Monday. It would have been a sizeable build. I sat with her for half an hour and asked what decision the report fed. It turned out she needed spend by a few business themes, and her categories lined up with groups of cost elements. So instead of custom code I built cost element groups for her themes and a layout on the standard cost center report, saved as a variant she could run herself, and we scheduled it to run every Monday. It took two days instead of weeks, and because it used standard objects it needed no upkeep through upgrades. Later she asked for two more views, and I showed her how to build them herself."