ERPClimb logoERPClimb

SAP FICO General Ledger Interview Questions

Interviewers use general ledger to test depth rather than coverage: the follow-up question is almost always "why does the system behave that way?", and that is where prepared answers usually run out.

General Ledger (G/L) is the central accounting component in SAP FI/FICO that records all business transactions in a company's books of accounts, providing the single source of truth for financial reporting. This parent overview orients learners across the full G/L learning path: accounting purpose, organizational structure (company code, chart of accounts, ledgers), master data (G/L accounts), configuration and posting logic, integration with sub-ledgers and other modules, period-end close controls, and how S/4HANA's Universal Journal (table ACDOCA) changes architecture and reporting compared to classic ECC. Detailed configuration, transaction-level postings, and specialized topics (parallel ledgers, document splitting, foreign currency valuation) are covered in dedicated child topics; this overview maps how they fit together and in what order to learn them.

This page carries 68 reviewed SAP FICO general ledger interview questions, each with a complete written answer and no sign-in required. The set breaks down into 20 foundational, 31 mid-level and 17 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

If you can handle every question here without hesitating, general ledger is unlikely to be what costs you an SAP FICO interview — and the same reasoning pattern transfers to the neighbouring topics linked at the bottom of this page.

68 General Ledger questions with answers

easyGeneral Ledger

1. What is a ledger in SAP S/4HANA General Ledger accounting, and how does the leading ledger relate to postings originating from Accounts Payable during year-end closing?

A ledger in S/4HANA represents a set of accounting-principle-specific data, typically tied to a fiscal year variant and posting period variant, that stores financial data for reporting purposes—for example, the leading ledger typically represents the group's primary accounting principle like IFRS, while additional non-leading ledgers can represent local GAAP or tax requirements. Every AP posting, such as a vendor invoice or payment, is by default reflected in the leading ledger and, where relevant, propagated to non-leading ledgers if it doesn't require different valuation. During year-end close, the leading ledger typically drives the primary financial statements and the balance carry-forward process, while non-leading ledgers may follow separate closing calendars for local statutory purposes. This means an AP invoice posted once appears consistently across ledgers unless a ledger-specific adjustment, such as a different provision, is required.
easyGeneral Ledger

2. During year-end close, a junior consultant notices that several vendor invoices posted via MIRO have hit a GL account that was never intended to receive automatic postings from MM, causing an unplanned balance at close. What steps should be taken to investigate and correct this?

First, check the GL account's field status group and whether it's flagged for automatic posting only, which would explain unintended manual overrides, but since these postings came from MIRO, the likely cause is incorrect account determination in MM (valuation class-to-GL account mapping in OBYC-type configuration) or a wrong purchase account assignment on the PO. I would review the affected documents in FB03, trace the account determination logic, correct the mapping, and post correcting/reclassification journal entries. Governance should include restricting who can change account determination and requiring change control review before year-end.
easyGeneral Ledger

3. Before executing a periodic recurring entry batch run that includes postings to bank-related GL accounts (such as recurring bank charges or standing interest accruals), what report or transaction would you use to review scheduled recurring documents, and what controls should you check to ensure accuracy before the postings hit the ledger?

Recurring entry templates are maintained via FBD1 (create), FBD2 (change) and FBD3 (display), each carrying a run schedule, next-run date, and posting date interval. Before the periodic run, use F.14 to list all recurring documents due in the target period so you can review account assignments, amounts, and posting dates in one place, ideally in test/batch-input session mode before final execution. For bank-related recurring postings, verify the target GL accounts are correctly set up (no open item management flag issues), the document type used has a valid number range, and posting periods are open in the posting period variant. Cross-check amounts against expected bank charge or interest schedules before releasing the batch session, since recurring documents post unchanged amounts every run unless manually updated.
easyGeneral Ledger

4. A vendor invoice for a purchase order is received in USD, while the PO was created in EUR, and the company code's local currency is GBP. Walk through how SAP calculates and posts the currency amounts and any exchange rate differences to the GL.

The PO carries EUR as its currency, but the invoice can be posted in a different currency such as USD if the vendor invoices that way; SAP translates the USD invoice amount to the PO currency (EUR) using the configured exchange rate type and rate, and compares it to the goods receipt value already posted in EUR. Both the EUR and USD-derived amounts are then translated to the company code's local currency (GBP) for GL posting, since every FI document stores amounts in transaction currency, local currency, and, if configured, group currency simultaneously. If the exchange rate used at invoice verification differs from the rate at goods receipt, the difference between the GR value and the invoice value in local currency is posted to a price or exchange rate difference account, not adjusted retroactively into the GR/IR account balance itself. The GL account master and MM account determination govern which difference account absorbs the variance.
easyGeneral Ledger

5. In S/4HANA, what organizational and financial fields does the Universal Journal (ACDOCA) capture for an Accounts Payable vendor invoice posting, and why does the BSEG table remain relevant despite ACDOCA's existence?

ACDOCA stores each line item with company code, business area, segment, profit center, cost center, functional area, ledger, and multiple currency amounts (transaction, local, group), combining FI and CO attributes into a single record for AP postings. BSEG remains the accounting document line-item table used for document processing and certain subledger logic (e.g., vendor-specific fields); it is not simply a compatibility view, and it continues to coexist with ACDOCA rather than being replaced by it. BKPF still holds header-level data such as document date, posting date, and document type for the same invoice.
easyGeneral Ledger

6. In S/4HANA, how does the Universal Journal capture a vendor invoice posting along with GL organizational elements such as company code, segment, and profit center, and why does this matter for basic Record-to-Report reconciliation?

When a vendor invoice posts, the Universal Journal writes a single line-item record in ACDOCA that includes the FI amounts along with organizational attributes like company code, segment, profit center, and business area on the same line, rather than these being spread across separate FI and CO tables as in ECC. This means the payable line and any derived splitting lines carry consistent organizational assignments, so AP balances can be sliced by segment or profit center directly from one source without reconciling FI and CO separately, simplifying trial balance and management reporting during close.
easyGeneral Ledger

7. A new team member attempts to post a manual FB01 journal entry directly to a vendor reconciliation GL account to correct a balance before year-end close, but the system rejects the posting with an error. As an entry-level consultant, explain why this happens and what account master setting causes it.

Reconciliation accounts are marked in the GL account master with a 'Recon. account for account type' field set to vendor (or customer/asset), which flags the account so it can only be updated indirectly through subledger postings like FB60, MIRO, or F-53, never by direct FI-only entries. This ensures the GL balance always stays synchronized with the AP subledger. To correct the underlying discrepancy, the consultant should identify and post the correction through the vendor account (which then automatically updates the reconciliation GL account) rather than trying to bypass the subledger by posting directly to the GL account.
easyGeneral Ledger

8. How does the Universal Journal simplify reconciliation between Accounts Payable and the General Ledger compared to the classic ECC architecture?

In ECC, AP subledger data lived in BSEG/BSIK and had to be periodically reconciled against GL totals in BSIS/summary tables, often requiring reconciliation reports to explain differences. In S/4HANA, every AP posting writes a single line in ACDOCA carrying both subledger detail (vendor, invoice reference) and GL attributes (company code, profit center, segment) simultaneously. This eliminates the separate totals table and index tables, so the AP subledger and GL are always in sync in real time, removing the need for periodic reconciliation runs between AP and GL balances.
easyGeneral Ledger

9. How does the Universal Journal (table ACDOCA) capture accounts payable invoice postings together with GL organizational structure elements such as company code, segment, and profit center, and why does this matter for financial reporting?

In S/4HANA, every AP invoice posted (e.g., via MIRO or FB60) writes a single line item into ACDOCA carrying both the vendor sub-ledger information and the full set of GL dimensions—company code, segment, profit center, business area, functional area—simultaneously. Unlike ECC where FI, CO, and New GL data lived in separate tables (BSEG, COEP, FAGLFLEXA) requiring reconciliation, ACDOCA eliminates reconciliation effort because sub-ledger and GL org-structure attributes are stored in one line. This gives real-time, drillable reporting by any organizational dimension without batch jobs or index tables.
easyGeneral Ledger

10. A newly hired FI consultant is asked to explain how the organizational structure linking company code to plant (via MM) impacts GL postings such as goods receipts and invoice receipts during period-end closing. Describe this integration and what could go wrong if the org structure is misaligned before close.

Each plant is assigned to a company code, and the plant's valuation area drives automatic account determination (via OBYC) so that goods receipts, invoice receipts, and inventory movements post to the correct GL accounts within that company code. During period-end closing, the MM period must be closed (via the MM period closing transaction) at or before the FI posting period lock, otherwise users could post material movements into a period that FI has already closed, or vice versa, blocking valid postings. If the plant-to-company-code assignment is misaligned, for example a plant incorrectly linked to the wrong company code, goods receipts could post GL entries to the wrong legal entity, creating intercompany imbalances and requiring correcting journal entries before books close. As a junior consultant, I'd verify the plant, valuation area, and company code assignments during any org structure change and confirm MM and FI period statuses are synchronized before finalizing the close.
easyGeneral Ledger

11. How does the Universal Journal (ACDOCA) change the way an Accounts Payable invoice is reflected in the general ledger compared to the classic ECC design with separate FI and CO tables?

In S/4HANA, ACDOCA is a single line-item table combining FI, CO, AA, and ML data. When an AP invoice posts, the vendor line and expense/GR-IR line are written once into ACDOCA with all dimensions (company code, cost center, profit center, segment) populated in real time. In ECC, FI data sat in BSEG/BKPF while CO data was reconciled separately via the reconciliation ledger, causing periodic mismatches. BSEG still exists and is updated for compatibility, but ACDOCA is now the single source of truth for reporting.
easyGeneral Ledger

12. During year-end closing, an AP clerk attempts to post a manual FB60 vendor invoice directly to a GL account normally updated only through automatic MM postings (e.g., GR/IR clearing), and the system blocks the posting. As a junior consultant, explain the likely cause and the account master governance control involved.

The GL account master likely has the 'Post Automatically Only' indicator set, which restricts manual document entry and permits postings only from automated processes such as MM goods receipt and invoice receipt. This control protects clearing and system-determined accounts from manual errors that could break reconciliation between MM and FI. The consultant should first confirm with the account owner why a manual posting was attempted; if a genuine correction is needed (e.g., resolving an orphaned GR/IR balance), a controlled adjustment process should be used rather than removing the flag, since disabling it permanently exposes the account to future erroneous manual entries.
easyGeneral Ledger

13. As a junior consultant, walk through the process of building a Financial Statement Version (FSV) that correctly reports vendor liabilities from Accounts Payable, including how reconciliation accounts and account groupings are handled within the hierarchy.

In OB58, you create a new FSV and define its top-level nodes such as Assets, Liabilities, and Equity, then build sub-nodes under Liabilities for items like Trade Payables. Within the Trade Payables node, you assign the GL account interval that includes the AP reconciliation account(s), since vendor open item balances post there via the vendor subledger rather than through direct GL entry. You also configure debit/credit indicators if the FSV needs to separate normal balances from reversed ones, and mark accounts as 'not assigned' initially to catch any GL accounts missing from the hierarchy. After building the structure, you test it by running the financial statement report (F.01 in ECC, or the Financial Statement app in S/4HANA) and validating that the trade payables total ties back to the AP aging report and trial balance before handing it over for sign-off.
easyGeneral Ledger

14. From a GL organizational-structure perspective, what does it mean that the Universal Journal stores company code, ledger, and business area directly on each Accounts Payable line item, and how does this simplify basic reconciliation compared to ECC?

In S/4HANA, every AP posting written to ACDOCA carries its full organizational context (company code, ledger, business area, profit center, segment) on the same line item, rather than splitting FI data in BKPF/BSEG and CO data in separate tables like COEP. This means a vendor invoice line already contains the dimensions needed for both financial and management reporting. In ECC, reconciling AP postings to CO or segment reporting required joining multiple tables and periodic reconciliation runs; in S/4HANA the single source of truth reduces reconciliation effort and lets reports like the compact document journal read organizational data directly, without additional matching logic.
easyGeneral Ledger

15. What is the Universal Journal in S/4HANA, and how does it change the way Accounts Payable postings are reflected in the general ledger compared to ECC?

The Universal Journal is the single line-item table ACDOCA that stores FI, CO, AA, and ML data together in one document. When an AP invoice posts via MIRO or FB60, ACDOCA immediately captures the GL account, company code, vendor reconciliation account, profit center, segment, and cost object in one record. In ECC, this data was fragmented across BSEG, COEP, and other tables requiring reconciliation jobs. In S/4HANA, real-time integration eliminates most periodic reconciliation between FI and CO, giving instant drill-down from financial statements to the originating vendor line item.
easyGeneral Ledger

16. During year-end close, a new hire posts a manual journal entry to a GL account that is normally updated only through automatic postings from goods receipt/invoice receipt in MM. What should you check as an entry-level consultant?

First check the GL account master (FS00) to see if it's flagged for automatic postings only, which would normally have prevented or flagged the manual entry, and review the field status group and account group to confirm proper restrictions were configured. Check whether the posting created an unreconciled balance versus the MM-driven balance on that account, typically a GR/IR-type clearing account. Review authorization roles to see why manual posting was even possible, and coordinate reversal of the incorrect entry with the AP/MM team before books close, documenting the control gap for governance follow-up.
easyGeneral Ledger

17. Why is it best practice to assign a dedicated number range to document types used for bank-related postings such as electronic bank statement postings, and how does this support reconciliation and audit reporting?

Assigning a dedicated number range to bank-related document types—such as those used for electronic bank statement postings, manual bank postings, or check processing—creates a distinct, contiguous sequence of document numbers isolated from other transaction types like vendor invoices or customer receipts. This makes it much easier for auditors and reconcilers to trace all bank-related entries for a period, since they can filter by document number range or document type without needing to inspect every line item. It also supports internal controls by making unauthorized or out-of-sequence bank postings easier to spot, and simplifies year-end bank reconciliation reporting where the volume of automatically generated bank statement documents can be large. Without a dedicated range, bank postings get interspersed with unrelated document numbers, complicating both audit trail analysis and troubleshooting of automatic postings from the bank statement program.
easyGeneral Ledger

18. What is the process to maintain a GL account master used as a house bank main account in S/4HANA, and how does the Universal Journal support real-time reconciliation between this GL account and the bank sub-ledger?

The house bank main account is created as a normal GL account via FS00 with an account group restricted to bank accounts, open item management typically switched off since bank balances aren't cleared item-by-item, and a field status group that allows relevant fields such as value date. It is then linked to a House Bank ID and Account ID in bank master configuration, which ties the GL account into the electronic bank statement (EBS) process. Every bank-related posting, whether from EBS import or manual bank entry, updates this GL account directly and simultaneously in ACDOCA, the single source of truth in S/4HANA. Because there is no separate bank sub-ledger table, reconciliation is effectively continuous: any bank statement line not matched by EBS posting rules shows up immediately as an open item or exception in the GL account, rather than requiring a separate month-end tie-out as in older architectures.
easyGeneral Ledger

19. At year-end, your team discovers several goods receipts from MM that have not yet been invoiced, leaving open balances on the GR/IR clearing account. As a junior FI consultant, what steps would you take to review and clean up these postings before the books close, and which account governance controls should be in place?

First, I'd run a GR/IR analysis report to identify open items grouped by age, PO, and vendor. For genuine timing differences—goods received but invoice not yet arrived—these are normal and typically handled by a reclassification/accrual posting that moves the GR/IR balance to a provision account for financial statement purposes, rather than being manually cleared. For items open beyond a reasonable period, I'd investigate with procurement whether the PO was fully received, cancelled, or if the invoice was booked against the wrong PO or account. Governance-wise, the GR/IR account should be a reconciliation-style account with open item management enabled, restricted to automatic postings from MM goods receipt and invoice verification, and periodically reviewed jointly by AP and procurement teams to prevent buildup of aged, unexplained balances before close.
easyGeneral Ledger

20. How does the Universal Journal (ACDOCA) integrate accounts payable postings with the general ledger in S/4HANA, and what reconciliation benefits does this provide compared to ECC?

In S/4HANA, every AP posting—whether a vendor invoice via FB60/MIRO or a payment via F110—writes directly into the Universal Journal table ACDOCA as a single line-item source. Unlike ECC, where FI, CO, AA, and reconciliation ledger data lived in separate tables requiring periodic reconciliation programs, ACDOCA merges the general ledger, cost accounting, and material ledger views into one document. This means the vendor subledger (BSEG) and the GL balance are always in sync because they derive from the same journal entry, eliminating classic GL-vs-subledger reconciliation runs. It also enables real-time drill-down from a financial statement line directly to the originating vendor invoice, without batch reconciliation jobs. Benefits include instant subledger-to-GL matching, elimination of separate CO reconciliation postings, and faster period-end close since no synchronization step is needed between AP and GL.
mediumGeneral Ledger

21. During year-end close configuration, what chart of accounts and GL account master settings ensure tax-relevant accounts are correctly identified for statutory tax reporting?

The GL account master's control data includes a 'Tax category' field that determines whether the account requires a tax code, is tax-relevant output/input only, or is tax-free. This is set at the chart of accounts segment level along with 'Posting without tax allowed' indicator. For statutory reporting, accounts feeding tax returns should be flagged consistently across all company codes sharing the chart of accounts, and account groups should segregate tax accounts (input VAT, output VAT, withholding tax payable) so tax reports and financial statement versions can pull accurate balances at year-end.
mediumGeneral Ledger

22. During year-end close configuration, what settings on the chart of accounts and GL account master ensure tax-relevant accounts are correctly identified for statutory tax reporting?

The GL account master's control data tab has a 'tax category' field that flags whether the account requires a tax code, is tax-relevant only, or posting without tax is allowed. Combined with the 'posting without tax allowed' indicator, this prevents postings that omit required tax codes. At year-end, tax reporting teams rely on this consistent flagging across accounts sharing the chart of accounts to extract tax-relevant balances for statutory filings. Configuration must align with country-specific tax procedures (e.g., TAXINN or similar) assigned at company code level, ensuring the account's tax category matches the applicable jurisdiction requirements.
mediumGeneral Ledger

23. What configuration steps in the chart of accounts ensure GL accounts requiring tax codes are correctly set up to support statutory tax reporting during year-end close?

In GL account master (FS00), the 'Tax category' field on the control data tab is set to determine whether the account requires a tax code, allows only input tax, only output tax, or is tax-relevant but with a specific code, and the 'Posting without tax allowed' checkbox controls whether non-tax postings are blocked. These settings must align with the account's nature—revenue and expense accounts typically require tax codes, while GR/IR or bank accounts usually don't. During year-end close, a review of tax-relevant accounts confirms no postings bypassed tax determination, which is essential for VAT/GST statutory filings.
mediumGeneral Ledger

24. What chart of accounts and GL account master configuration steps ensure tax-relevant accounts are correctly set up to support statutory tax reporting during year-end close?

You configure the operational chart of accounts with a clear account grouping, and on each tax-relevant GL account master (FS00) set the 'Tax category' field to indicate whether input tax, output tax, or both are allowed, and flag 'Posting without tax allowed' as needed to enforce tax code entry. Country-specific chart of accounts can be assigned where local statutory reporting differs from the operational COA. Field status groups should make the tax code field mandatory on relevant expense/revenue accounts. At year-end, these settings are validated against tax reports to confirm every tax-relevant posting carried a valid tax code.
mediumGeneral Ledger

25. From a controls perspective, how do field status groups on GL revenue and receivable accounts prevent incomplete postings originating from SD billing documents, and why is this particularly important during year-end close?

The field status group assigned to a GL account determines which fields—such as profit center, segment, cost center, or business area—are mandatory, optional, or suppressed when a posting hits that account, including postings generated automatically from SD billing document release to accounting. If a revenue or receivable account's field status group makes profit center or segment mandatory, incomplete SD-to-FI postings, for example due to a pricing condition or output determination gap, will be rejected at the source rather than posting with blank organizational data. This is critical at year-end because incomplete organizational assignments on revenue lines would corrupt segment or profit center reporting used for the financial statements and any statutory segment disclosures, and errors are far harder to correct after period close and consolidation than to catch at the point of entry. The posting key's field status also combines with the account's field status, with the stricter rule prevailing.
mediumGeneral Ledger

26. What reports or checks would you use to monitor number range consumption for bank-statement-related document types, and why does dedicated numbering matter for Record-to-Report audit trails?

I would review the number range intervals assigned to the document type used for electronic bank statement postings and periodically check the current number status against the upper limit to anticipate exhaustion before it interrupts high-volume postings, particularly in companies with many daily bank transactions. Dedicating a separate number range to bank-related document types keeps postings sequentially traceable per source, supports easier audit trail reconstruction, and prevents overlap with other document types that could complicate reconciliation between bank sub-ledger activity and the GL during period-end close and external audits.
mediumGeneral Ledger

27. Users report that AR line items posted via a custom document type show reversed debit/credit signs in the customer line-item display, though the trial balance is correct. As the FI consultant, how do you use posting key configuration to diagnose this?

Check the posting key configuration for the debit/credit indicator assigned to the posting keys used with the custom document type, since a posting key incorrectly flagged as debit when it should be credit (or vice versa) can distort line-item display while the document still balances overall at the header level. Compare the custom keys against standard SAP posting keys (e.g., 01 debit invoice, 11 credit memo) to spot the deviation, and also verify field status group and special GL indicator associations tied to those keys. Correct the root cause by reassigning the proper posting key configuration, testing thoroughly in a non-production client before applying to production.
mediumGeneral Ledger

28. During year-end close, your multinational company runs automatic retained earnings carry-forward, but you later discover that a withholding tax correction posted after the carry-forward run created a discrepancy between the local currency and group currency retained earnings balances feeding into consolidation. Walk through how retained earnings determination and balance carry-forward work, and how you would investigate and correct this before consolidation.

Retained earnings determination is configured via OB53, where each P&L account type is mapped to a retained earnings GL account; at fiscal year-end, the balance carry-forward program moves net P&L balances into that account for the new fiscal year, and because the Universal Journal stores local, group, and hard currency amounts simultaneously per line item, each currency's retained earnings is carried forward from its own accumulated balance, not derived by translating one currency into another. If a late tax correction posts to a P&L account after the carry-forward has already run, the correction updates the prior year's P&L balance but the new year's retained earnings carry-forward figure won't automatically reflect it until the carry-forward program is re-executed. I would identify the affected company codes/ledgers, confirm the correction posted to the correct fiscal year and ledger, then re-run the balance carry-forward for the affected accounts and periods, and validate both local and group currency retained earnings tie out before consolidation extraction.
mediumGeneral Ledger

29. An AR aging report shows customer credit memos appearing as positive (debit) balances instead of reducing the receivable, distorting the report during month-end close. How would you use posting keys to diagnose and resolve this?

I'd start by reviewing the posting key used on the credit memo document type in transaction OBA7/document type configuration and the standard posting keys assigned (e.g., 11 for credit memo debit customer reversal vs 01 for invoice). If someone manually posted the credit memo using an invoice posting key (01/debit) instead of the correct credit posting key (crediting the customer), the sign would be reversed in the report. I'd verify via FBL5N whether the document uses the wrong key, correct future postings by restricting entry via a dedicated document type/screen variant, and reclassify the incorrect open items.
mediumGeneral Ledger

30. In an S/4HANA environment where SD billing documents generate deferred revenue recognition schedules, explain how manual GL accrual postings differ from SD-driven revenue accrual/deferral, and why ledger configuration matters when accruals must satisfy both local statutory and group reporting requirements.

Manual accruals are posted directly to GL, typically via a recurring or one-time journal entry (e.g., using an accrual document type), reversed automatically the following period, and are entirely FI-driven with no link back to a sales order or billing document. SD-driven accruals originate from billing document conditions or event-based revenue recognition logic, which automatically defers or recognizes revenue over a contract period and posts to GL through the SD-FI integration, keeping the deferred revenue balance auditable back to the sales order. Ledger configuration matters because if local GAAP requires immediate accrual recognition while group IFRS reporting requires deferral (or vice versa), the posting must target the correct ledger group so only the relevant accounting principle's ledger is updated, avoiding cross-contamination of local statutory books and group consolidation figures.
mediumGeneral Ledger

31. How do number ranges assigned to bank-related document types support GL line-item reporting and audit trail requirements in a Record-to-Report process?

Each document type used for bank postings (like electronic bank statement entries or manual bank journal entries) is linked to a distinct number range, which produces a contiguous, gapless sequence of document numbers within that range for the fiscal year. This lets auditors and reporting teams filter GL line-item reports (e.g., FBL3N) by document type and number range to isolate all bank-driven postings, verify completeness by checking for number gaps, and trace any posting back to its source process without ambiguity. Using shared number ranges across unrelated document types would make this filtering and gap analysis unreliable.
mediumGeneral Ledger

32. During month-end close, customer down payment postings appear with a debit balance in the AR aging report instead of properly offsetting the receivable. How would you use posting key configuration to diagnose the issue?

I'd start by reviewing the posting keys used for the special GL down payment transaction (typically debit/credit pair tied to the special GL indicator) in OBXR/OBXT-type configuration to confirm the correct debit/credit indicator and account type are assigned. Next, check whether the posting key's 'reversal' logic or sign is inconsistent with how the aging report sums special GL balances. I'd also verify the special GL indicator's reconciliation account assignment and confirm posting keys 09/19 (or configured equivalents) are correctly mapped to debit and credit postings respectively. Correcting a mismatched posting key assignment usually resolves the sign distortion.
mediumGeneral Ledger

33. During year-end close configuration, what settings on the chart of accounts and GL account master ensure tax-relevant accounts are correctly restricted to specific tax categories, and how does this support statutory tax reporting across multiple countries sharing one chart of accounts?

On the GL account master, the tax category field on the company code segment determines whether the account requires a tax code (input, output, or both), and the 'posting without tax allowed' indicator controls whether non-tax postings are permitted. For multinational operations sharing one operational chart of accounts, country-specific tax reporting is supported by assigning a country/group chart of accounts and mapping local statutory accounts via the alternative account number field, while consistent tax category settings across company codes prevent postings that would misstate VAT/output tax accounts during statutory filing.
mediumGeneral Ledger

34. In the Record-to-Report process, how does the reconciliation of Accounts Receivable open items support the general ledger reporting close, and what controls ensure the AR reconciliation account balance always ties to the subledger?

AR postings always hit a reconciliation account configured on the customer master, and SAP prevents direct manual postings to this account, forcing all customer transactions through AR sub-ledger transactions such as FB70, F-28, or SD billing. During closing, the GL balance on the reconciliation account must equal the sum of open customer line items in the sub-ledger, since every sub-ledger posting simultaneously updates the reconciliation account in real time (in S/4HANA both live in ACDOCA). Reports such as customer line item display and aging analysis are compared against the GL account balance to validate the tie-out. If a mismatch appears, causes typically include manual journal entries that bypassed subledger controls, incorrect account assignment during data migration, or a reconciliation account change on a customer master with open items. Closing checklists should include this reconciliation as a mandatory control before finalizing the AR-to-GL close.
mediumGeneral Ledger

35. During year-end close, how do you configure the chart of accounts setup (operational, country/group) to support both statutory tax reporting and group consolidation across multiple countries?

The operational chart of accounts is assigned to the company code and used for daily postings and financial statements. When local statutory/tax reporting requires a different account structure (e.g., country-specific numbering mandated by local tax authorities), you assign an alternative/country chart of accounts to the company code and maintain the alternative account number on each GL master. At year-end, tax reporting programs and financial statement versions can be built off the country chart of accounts to produce statutory filings, while the operational chart drives the leading ledger's financial statements. For group reporting, a group chart of accounts with account group mapping is used at consolidation. Configuration involves defining the additional chart of accounts, assigning it in company code global parameters, and maintaining the alternative account number field on each GL account master to link operational and country charts.
mediumGeneral Ledger

36. During year-end close configuration, how do you use the country/group chart of accounts and alternative account number field on the GL master to satisfy local statutory tax reporting requirements while maintaining a single operating chart of accounts for group reporting?

Each company code is assigned an operating chart of accounts for daily posting and group reporting, plus optionally a country-specific chart of accounts for statutory filing. On the GL account master, the 'alternative account number' field maps the operating account to the corresponding country chart of accounts account. During year-end tax reporting, local statutory reports (like a country-specific financial statement version) are built using these alternative numbers, while consolidation and group reports use the operating chart. This lets you maintain one GL account structure globally while satisfying jurisdiction-specific tax and statutory numbering requirements without duplicating master data.
mediumGeneral Ledger

37. How are number ranges linked to document types for bank-related postings, and what would you check to ensure the number range interval doesn't run out during high-volume electronic bank statement processing?

Each document type is assigned a number range object, and every posting of that document type consumes the next available number in the interval for the fiscal year. For high-volume bank postings like electronic bank statement (EBS) documents, I'd review the number range interval assignment (transaction FBN1) to confirm sufficient capacity for expected annual volume, and monitor consumption periodically, especially before peak periods like month-end or year-end. If the interval is close to exhaustion, I'd extend it before the fiscal year starts, since number ranges are year-dependent and running out mid-year blocks all postings of that document type until corrected.
mediumGeneral Ledger

38. What configuration elements control vendor invoice postings during year-end close to ensure proper document control, and how do these settings help prevent postings after the books are locked?

Document control for AP postings during close relies on several linked configurations working together. The document type (for example KR for vendor invoices) controls the allowed account types and number range assignment. The posting period variant, maintained via OB52, defines which periods are open per account type, and is often restricted so only AP account types remain open for a short grace period after the GL is locked. Field status groups on the vendor reconciliation account and expense accounts enforce mandatory fields, such as cost center or tax code, so invoices cannot post incompletely. Authorization roles should also restrict who can post to AP after the standard close date, commonly using period-specific authorization groups. Together these layered controls prevent invoices from posting unintentionally to a closed period, force correct account assignment, and route legitimate late invoices through a controlled manual override process requiring approval, keeping a clean audit trail through year-end.
mediumGeneral Ledger

39. How are number ranges linked to document types in SAP FI, and what year-end considerations should you review to ensure number range intervals don't run out for high-volume bank-related postings such as electronic bank statement documents?

Each document type is assigned a number range object/interval, defined either per fiscal year or as year-independent, which determines the sequential number series assigned to documents posted with that type. Bank posting document types with high transaction volumes, such as electronic bank statement postings, can exhaust the assigned interval before year-end if not monitored, causing posting failures. Before year-end, review the current number status against the interval's upper limit, and if the interval is year-dependent, ensure the following year's range is created in advance; also confirm whether the interval is buffered, since buffering improves performance under concurrency but can create number gaps.
mediumGeneral Ledger

40. A multinational client posts vendor invoices across several company codes sharing one chart of accounts, but tax reporting teams notice that some invoices generate no separate tax line item in the GL document, even though a tax code was entered. As the FI consultant, how would you use posting keys and related configuration to diagnose why tax lines aren't being generated consistently?

Tax line generation depends on the combination of posting key configuration and account/tax code setup, not posting keys alone. First check whether the posting key used for the invoice line, such as 31 for vendor credit or 40/50 for GL debit/credit, is flagged to allow tax processing at all; if 'no tax allowed' is set on that key, tax fields are suppressed regardless of the tax code entered. Next verify the GL account's tax category field: if set to '-' for only input tax, or blank for postings without tax, and a tax code was still entered, SAP may error or handle the line inconsistently. Also check the tax code configuration (FTXP) and whether it's relevant for the country and tax procedure used by that specific company code, since tax procedures can differ by country even under one shared chart of accounts. Finally, confirm the posting key's field status doesn't suppress tax fields, hiding entry even when the underlying calculation logic is correct.
mediumGeneral Ledger

41. Your chart of accounts is shared across multiple company codes with different VAT/tax reporting requirements. During year-end closing configuration, what settings ensure tax-relevant GL accounts are correctly identified, segregated, and reconciled for statutory tax filings?

Tax relevance is controlled at the GL account master level via the 'tax category' field (input tax, output tax, or blank for not tax relevant) plus the 'posting without tax allowed' indicator. Field status groups should mandate tax code entry on accounts where tax is required, and account groups/number ranges should keep tax accounts (e.g., VAT payable/receivable) in a distinct, easily identifiable range. During closing, reconcile the balances on these tax accounts against the tax reporting output generated for each jurisdiction; mismatches usually stem from manual journal entries posted without a tax code or postings misassigned to the wrong company code sharing the chart of accounts.
mediumGeneral Ledger

42. What is the difference between a fiscal-year-dependent and a fiscal-year-independent number range for a document type used in bank-related postings, and why does this distinction matter for Record-to-Report bank reconciliation reporting?

A fiscal-year-dependent number range resets or requires a new interval each fiscal year, so document numbers can repeat across years but stay unique within a company code and fiscal year combination; a fiscal-year-independent range continues numbering across years without reset. For bank-related document types used in high-volume electronic bank statement processing, year-dependent ranges require timely year-end maintenance (defining next year's interval) or postings fail at year-end/year-start, disrupting bank reconciliation. Independent ranges reduce that maintenance risk but can exhaust the interval faster if volumes are high, so monitoring consumption is still required either way for uninterrupted reporting.
mediumGeneral Ledger

43. During month-end AR aging review, you notice that customer invoices posted through a custom sales-related document type are missing from the customer open item report, even though the corresponding revenue lines appear correctly in the GL revenue account. Walk through how you would use posting key configuration to find the root cause.

Start by checking the posting keys used on the customer line in these documents via OB41. Confirm the account type is 'D' (customer) and that the posting key is not accidentally configured with a special GL indicator or an alternative reconciliation account override, which would post the amount to the customer sub-ledger under a different reconciliation account than the standard AR account. Also verify the debit/credit indicator and whether the 'sales-related' flag is set correctly, since this affects credit management and open item relevance. Compare against a standard posting key like 01/11 used for normal invoices, and check if a substitution rule is silently redirecting the posting key.
mediumGeneral Ledger

44. During month-end AR reconciliation, customer bill-of-exchange receivable postings show up with incorrect debit/credit signs in the customer line-item report used for cash forecasting, even though the trial balance nets to zero correctly. How would you use posting key configuration to diagnose and correct this?

I would review the posting keys used for the bill-of-exchange special GL transaction in OB41, checking whether the debit/credit indicator and the special GL indicator assignment match the intended transaction type (e.g., posting key 09 for customer debit vs 19 for customer credit under a special GL indicator). Since the trial balance nets correctly, the issue likely isn't a wrong GL account but a swapped posting key on one leg of the transaction, causing the customer line item to display with the wrong sign in reports like FBL5N. I would trace a sample document, compare posting keys against SAP standard configuration, and correct the assignment or the transaction variant used for bill-of-exchange postings.
mediumGeneral Ledger

45. During month-end close, AR line items posted through a custom document type appear with a debit balance for what should be a credit memo, distorting the customer aging report even though the trial balance is correct. How would you diagnose this using posting key configuration?

I would check the posting key assigned to the credit memo transaction in the custom document type's configuration and confirm its debit/credit indicator and account type. If the wrong posting key (e.g., a debit-indicator key normally used for invoices) was mistakenly configured or selected during entry, the customer line item would display incorrectly even though the offsetting GL entry balances the document overall. I'd verify in OB41-type posting key configuration that credit memo postings use posting keys with the correct sign and reconciliation account type, then correct the transaction variant or user entry process to prevent recurrence.
mediumGeneral Ledger

46. What report or transaction would you use to check the current number range status for a bank-posting-relevant document type before a high-volume electronic bank statement run, and what year-end audit trail risk arises if that document type is configured with an external, rather than internal, number range?

You would review the number range object assigned to the bank posting document type via the number range maintenance transaction (FBN1) to check the current interval, year assignment, and last number used, confirming sufficient capacity remains for the expected volume. If the document type uses an external number range, document numbers are supplied by an outside system or manual entry rather than assigned sequentially by SAP, which increases the risk of duplicate numbers, gaps, or numbers issued out of sequence. For Record-to-Report audit trail purposes, this makes it harder to demonstrate a complete, gapless sequence of postings, which auditors typically expect for high-volume automated processes like EBS.
mediumGeneral Ledger

47. During year-end close, the CO-FI reconciliation posting run triggered by cross-controlling-area cost allocations fails, and the error log shows the assigned FI document type has exhausted its number range for the fiscal year. As a junior consultant supporting production, how would you diagnose and resolve this before the close deadline, and what should be checked to prevent recurrence?

First, identify the exact FI document type used for CO-to-FI reconciliation postings, usually a dedicated type separate from manual entries, and check its number range status and current interval via document type and number range configuration to confirm it is genuinely exhausted for the current fiscal year rather than a year-transition setup issue. If truly exhausted, extend the number range interval for the current fiscal year immediately; this is a configuration change and, depending on the landscape, may need emergency change control if it must move through transport to production. Once postings succeed and the close proceeds, review historical posting volume trends to size the interval appropriately going forward, since CO allocation and settlement runs can generate high volumes especially at period-end. Also verify the number range isn't unintentionally shared with other document types or company codes causing faster-than-expected consumption, and document the incident with a proactive number range monitoring check ahead of future closes.
mediumGeneral Ledger

48. Users report that customer down-payment postings show up with an unexpected debit/credit sign in the AR aging report, distorting the GL reconciliation. How would you use posting keys to diagnose the issue, and what is typically misconfigured?

Posting keys control the debit/credit indicator, account type, and field status for a line item—not the special GL indicator itself, which drives the alternative reconciliation account substitution. If down payments display with the wrong sign in aging, I'd first check whether the correct posting key for the special GL down payment process was used at entry, since using a standard invoice posting key instead of the special GL posting key would post to the normal reconciliation account and misrepresent aging. I'd review the posting key configuration to confirm the account type is 'D' (customer) with the correct debit/credit setting, and that the special GL indicator's field status allows entry. A common misconfiguration is assigning the wrong posting key in the customer down payment request variant, or a custom posting key with an incorrect debit/credit indicator, causing the down payment to net incorrectly against normal receivables in aging reports.
mediumGeneral Ledger

49. How do you configure parallel accounting in S/4HANA to handle different valuation requirements, such as IFRS versus local GAAP with different tax depreciation rules, across accounting principles, and what governance is needed over GL account master data to support this?

Parallel accounting in S/4HANA is typically implemented using the ledger approach: you define multiple ledgers—leading ledger for group/IFRS, non-leading ledger(s) for local GAAP or tax—each linked to an accounting principle, and assign them to the relevant company codes. Where valuation genuinely differs, such as different depreciation methods for tax purposes, you configure separate depreciation areas in Asset Accounting posting to the corresponding ledger group, so only the ledger-specific document carries the differential posting. Governance-wise, GL account master data must be carefully controlled so accounts used for principle-specific adjustments, such as a local-GAAP-only provision account, are correctly flagged for the right usage, and changes to key fields like account type or field status require a change-control process since master data is shared across ledgers, not duplicated. Regular reconciliation of ledger balances against source documents helps confirm parallel postings are landing correctly.
mediumGeneral Ledger

50. During year-end close, your reporting team discovers that certain SD billing document revenue postings are hitting a GL account that isn't correctly grouped under 'Revenue' in the Financial Statement Version, causing the income statement to misstate gross revenue. As the FI consultant, how would you investigate the chart of accounts and account determination setup, and correct this before financial statements are finalized?

First, trace the SD document flow to identify which condition type and account key in the pricing procedure determined the GL account via account determination (VKOA), and verify whether the account posted actually matches the intended revenue account in the operational chart of accounts. Then check its assignment in the Financial Statement Version hierarchy. If the account is correctly a revenue account but placed under the wrong FSV node, the fix is at the FSV mapping level, and simply correcting the node reference resolves the reporting distortion without touching posted data. If instead the wrong GL account was actually posted due to a VKOA condition table error, correct the account determination going forward and consider a manual reclassification journal entry for the amounts already misposted. Any correction found this late must be documented, reviewed for materiality, and approved as part of the close checklist, with tightly controlled access to FSV and account determination changes to prevent recurrence.
mediumGeneral Ledger

51. During year-end close, you find long-outstanding open items sitting on a customer reconciliation account, distorting the AR aging report and preventing clean GL-to-subledger reconciliation. How would you investigate and resolve this, and what document control settings are relevant?

I'd start by reviewing open items filtered by aging to identify which items are stuck—commonly caused by partial payments not matched to the right invoice, disputed items awaiting a credit memo, or postings with mismatched assignment or reference fields that prevent automatic clearing from matching them. Since the reconciliation account itself doesn't allow direct posting, I'd trace each stuck item back to its origin document and check whether a clearing document exists but wasn't properly linked, for example due to a currency or exchange rate difference causing a small residual. Resolution options include manual clearing with a small write-off within tolerance group limits for genuine rounding differences, correcting assignment fields to enable auto-clearing next run, or escalating unresolved disputes so they're clearly flagged rather than left ambiguous in the standard aging view. Document control checks include reviewing the account's open item management flag, automatic clearing matching criteria, and tolerance groups used for allowable write-off amounts.
hardGeneral Ledger

52. Your organization posts intercompany invoices in multiple transaction currencies using a dedicated document type before results feed into SAP Group Reporting for consolidation at year-end. How does the currency configuration on this document type affect the consolidation outcome, and what can go wrong?

The document type itself doesn't fix currency, but its number range and posting behavior are typically paired with configuration ensuring all intercompany documents capture transaction currency, company code currency, and group currency simultaneously in ACDOCA. If the group currency isn't properly maintained at company code level or the document type is used inconsistently across entities, currency translation differences can appear in consolidation, causing intercompany elimination mismatches. Common issues include exchange rate type inconsistencies between operational postings and the rate type used by Group Reporting, leading to residual differences that must be manually investigated during consolidation close.
hardGeneral Ledger

53. Your organization runs foreign currency valuation at year-end using a dedicated document type before the resulting balances feed into SAP Group Reporting for consolidation. Explain how document type configuration influences this valuation-to-consolidation flow, and what can go wrong if it's misconfigured.

Foreign currency valuation posts unrealized FX gain/loss adjustments using a configured valuation document type, which determines the number range, whether the document reverses automatically in the next period, and which account types are permitted to post. For consolidation, these valuation postings must be identifiable and often treated differently in the group reporting data collection, since they represent unrealized adjustments rather than transactional activity and may need distinct handling during intercompany elimination. If the document type isn't configured to trigger automatic reversal, unrealized gains/losses can double up in the following period. If the group reporting mapping doesn't recognize the valuation document type separately, unrealized FX adjustments could get consolidated as if they were realized transactions, distorting group P&L. Correct setup requires coordinating the valuation document type, its reversal method, and the consolidation data collection's transaction type mapping.
hardGeneral Ledger

54. Your organization posts intercompany invoices in multiple transaction currencies, and a dedicated document type is used for these cross-border postings before results feed into SAP Group Reporting for consolidation. How does the currency configuration on this document type affect the consolidation outcome, and what can go wrong?

The document type itself doesn't directly hold currency conversion logic, but it's linked to number ranges and controls whether certain fields (like reference currency) are mandatory, and combined with the exchange rate type assigned at company code or document level, it determines how transaction currency amounts are translated to company code and group currency in ACDOCA. If the wrong exchange rate type or an outdated rate is used for intercompany postings, group currency amounts feeding Group Reporting will be inconsistent between the two intercompany partners, causing IC mismatches during consolidation elimination. Governance requires locking exchange rate types per document type/scenario and validating rates before month-end.
hardGeneral Ledger

55. Your organization uses a dedicated document type for year-end foreign currency valuation postings before results feed into SAP Group Reporting for consolidation. How does the document type's currency configuration affect this valuation-to-consolidation flow, and what can go wrong if misconfigured?

The document type used for valuation postings (e.g., via F.05) controls whether postings are allowed to update in specific currency types and whether the document is treated as reversible/technical. If the document type isn't configured to permit posting in the required currencies (transaction, local, group), the valuation adjustment may not flow correctly into all currency fields in ACDOCA, causing group currency balances passed to Group Reporting to be understated or missing entirely. Misconfiguration can also cause the reversal posting logic to fail, leaving stale valuation entries. Governance requires validating the document type's currency settings and reversal behavior before each year-end run.
hardGeneral Ledger

56. In a multi-ledger S/4HANA landscape, SD billing documents post revenue automatically, and the leading ledger requires profit center as a mandatory document splitting characteristic. A non-leading ledger carrying a different accounting principle has a GL account field status group that suppresses the profit center field entirely. As a result, document splitting fails intermittently for these SD-driven postings under the non-leading ledger's accounting principle. As the architect, how would you diagnose and redesign this?

The root cause is a conflict between the document splitting configuration, which expects profit center as a mandatory splitting characteristic across all relevant ledgers, and the GL account's field status group, which suppresses that same field for entry. Diagnose by checking the field status group assigned to the revenue GL account and comparing it against the splitting characteristics configuration; suppression at field status level blocks the value even when splitting logic tries to derive or validate it. The fix is to align field status groups so profit center is at minimum optional (ideally required) on all accounts feeding ledgers where it's a mandatory splitting characteristic, and to confirm this consistently across accounting principles rather than per company code alone.
hardGeneral Ledger

57. In a group with significant intercompany trading, intercompany clearing accounts must reconcile perfectly before consolidation. Explain how the trading partner and company code fields on clearing postings support this reconciliation, and what typically causes intercompany mismatches feeding into SAP Group Reporting.

Intercompany transactions are recorded with the trading partner field, populated from the counterparty company code, on both sides of the transaction, allowing consolidation to match, for example, Company A's intercompany receivable against Company B's intercompany payable for the same trading relationship. The GL organizational structure must ensure every company code involved in intercompany trade has a corresponding trading partner assignment maintained in its company code global data, and that both sides post to designated intercompany clearing accounts consistently. Typical causes of mismatches feeding into consolidation include one side posting to a non-designated GL account instead of the intercompany clearing account, timing differences where one company books the transaction in a different period than the counterparty, missing or incorrect trading partner on a manual journal entry, and currency translation differences when the two entities use different local currencies for the same intercompany balance. Resolution typically involves a monthly intercompany reconciliation comparing both sides by trading partner and account before consolidation data collection.
hardGeneral Ledger

58. Users report that FI postings integrated from CO (such as assessment cycle settlements) are being blocked by a validation rule meant to prevent postings to statistical cost centers, but the rule is also incorrectly blocking valid postings originating from a different controlling area. As the architect, how would you troubleshoot and redesign this validation to eliminate the unintended cross-controlling-area blocking without degrading posting performance?

I would first identify the validation's call point and boolean structure in the validation/substitution configuration, checking whether the prerequisite condition references cost center attributes without also filtering on controlling area or company code, which is the likely root cause of the rule firing too broadly. I'd reproduce the failure by simulating the posting for both the affected and unaffected controlling areas, tracing which check statement evaluates true incorrectly. The fix typically involves tightening the prerequisite logic to include controlling area or a more specific cost center category check rather than a blanket cost center attribute test, and testing this in a non-production client against representative postings from all impacted controlling areas before transport. For performance, I'd avoid overly complex nested boolean logic at the line-item call point, and consider whether the check truly needs to run at that call point versus header level, since validations execute for every relevant posting and unnecessary complexity adds overhead at scale.
hardGeneral Ledger

59. Your organization uses a dedicated document type for manual intercompany profit elimination postings feeding SAP Group Reporting at year-end, and these postings must handle currency differently from standard operational transactions. Explain how document type currency configuration influences the consolidation outcome, and what can go wrong if misconfigured.

The document type itself doesn't directly set currency rules, but it's typically linked with specific number ranges and posting authorizations that restrict elimination postings to designated users and accounts, while the currency handling comes from the posting transaction and company code currency settings applied when the elimination entry is created. If the elimination postings are entered in local currency without correctly triggering group currency translation, or if the wrong exchange rate type is used versus operational postings, the consolidated figures in Group Reporting will not tie to the sum of local ledgers, causing consolidation mismatches that surface during trial balance upload validation.
hardGeneral Ledger

60. At year-end close, an SD billing document posts revenue to a shared GL account, but the profit center field is optional in the field status group for one company code while suppressed in another, causing document splitting inconsistencies and segment reporting breaks. As the architect, how would you diagnose and redesign the field status configuration?

I'd first compare the field status group assigned to the revenue account across both company codes and check whether they're linked to the same or different field status variants. If document splitting is active and profit center is a mandatory split characteristic, suppressing the field in one company code's field status group directly conflicts with the splitting rule, causing incomplete or inconsistent splitting results. I would standardize the field status group for shared revenue accounts to require the profit center field wherever document splitting is configured to derive it, then retest postings from SD billing to confirm consistent segment population before finalizing close.
hardGeneral Ledger

61. Walk through the process of maintaining GL master data in a multi-ledger S/4HANA landscape where a P&L account must also function as a cost element for CO, and where different ledgers use different fiscal year variants for parallel reporting.

In S/4HANA, cost elements are derived automatically from P&L GL accounts, so maintaining the GL master with the correct account type and, where applicable, cost element category is the primary control point rather than maintaining a separate CO master record. Where ledgers use different fiscal year variants, you confirm the account is assigned consistently across all ledgers via the ledger-specific settings, and validate that CO postings derived from these accounts reconcile with each ledger's period-end balances. As architect, you'd run test postings across both ledgers, check FAGLL03H drilldowns, and confirm CO real-time integration doesn't create timing mismatches at period boundaries caused by variant differences.
hardGeneral Ledger

62. In a multi-ledger S/4HANA landscape supporting parallel accounting, walk through how you would design GL master data and ledger assignment to ensure CO postings reconcile correctly across a leading ledger and a non-leading ledger with different depreciation approaches.

I would first confirm the accounting principle assignment to each ledger, then ensure GL accounts used for asset-related postings are open for all relevant ledgers with consistent field status. Cost elements derived from P&L accounts must exist consistently regardless of ledger, since CO objects (cost centers, orders) are ledger-independent in the operational sense but postings can carry ledger-group-specific amounts via FI-CO real-time integration. Depreciation differences between ledgers are handled through separate depreciation areas posting to different ledger groups, so I'd validate that asset accounting's depreciation area-to-ledger mapping aligns with the GL ledger group assignment to avoid CO reconciliation breaks.
hardGeneral Ledger

63. Walk through the process of maintaining a GL account master that must function as both a P&L account for external reporting and a cost element for CO, when the organization uses multiple ledgers with different fiscal year variants.

When a P&L GL account is created, if it maps to a cost-relevant transaction, a primary cost element is automatically derived in S/4HANA (cost element category typically 1) since GL master and cost element master are merged. The account must be assigned a default cost center or CO object via OKB9 or account assignment rules so postings don't error out for missing CO assignment. With multiple ledgers on different fiscal year variants, care is needed because CO postings follow the controlling area's fiscal year variant, so reconciliation and period-end allocations must map correctly to each ledger's periods, especially at non-leading ledger closes with offset fiscal years.
hardGeneral Ledger

64. Your group consolidation team requires that manual intercompany profit elimination postings use a dedicated document type with distinct currency handling from standard operational postings. Explain how document type configuration influences how these eliminations are captured in ACDOCA and passed to SAP Group Reporting, and what can go wrong if misconfigured.

The document type itself primarily controls the number range, allowed account types, and posting authorization, restricting which users can post through it; it does not directly fix the currency. Actual currency values in ACDOCA are driven by the ledger's currency settings and the exchange rate type applied at posting, along with whether amounts are entered directly in group currency or translated. If the elimination document type isn't restricted to authorized consolidation postings, unrelated users could post through it, contaminating the population used for elimination reporting. If the exchange rate type used for these postings differs from the rate type used elsewhere, ACDOCA will show inconsistent group currency values, requiring reconciliation before SAP Group Reporting import.
hardGeneral Ledger

65. Your organization posts periodic GR/IR true-up reclassification entries using a dedicated document type before results feed into SAP Group Reporting at year-end. This document type is configured to allow postings only in company code (local) currency, yet the parent requires group currency translation for consolidation. Explain how this currency restriction affects the consolidation load, and what typically goes wrong.

If the document type restricts postings to local currency only, the GR/IR true-up entries won't carry a native group currency amount in ACDOCA; instead, the group currency value gets derived later through the standard exchange rate translation applied at consolidation load time rather than the rate in effect when the entry was posted. This can create timing mismatches if the translation rate used at consolidation differs from the rate applicable on the posting date, especially for entries made near period-end. The typical failure is unexplained consolidation variances between local and group currency retained earnings, traced back to this document type not capturing group currency at the point of posting.
hardGeneral Ledger

66. Your organization posts manual intercompany profit elimination entries at year-end using a dedicated document type restricted to only allow group currency (currency type '30' or similar) postings, before results feed into SAP Group Reporting. Local statutory financial statements at the legal entity level then show a mismatch against the consolidated figures. Walk through how document type currency configuration causes this, and how you would resolve it.

If the document type is restricted so only group currency postings are permitted, the elimination entries never generate a corresponding local currency (company code currency) line in the local ledger, meaning statutory reports at the entity level don't reflect the elimination while the consolidated group view does. This creates a structural mismatch rather than a timing difference. The fix is to allow the document type to post in both local and group currency simultaneously (or use a document type without currency-type restriction) so ACDOCA carries both amounts consistently, ensuring the local trial balance and the consolidated elimination amounts stay reconcilable back to source.
hardGeneral Ledger

67. You are designing the global posting period strategy for a multinational S/4HANA rollout spanning 40 company codes with varying statutory year-ends, alongside Asset Accounting depreciation runs that must close before FI periods lock. How would you architect posting period variants and their coordination with Asset Accounting closing to avoid cross-module conflicts?

I'd group company codes sharing the same fiscal year variant and closing calendar into common posting period variants rather than creating one variant per company code, to reduce maintenance overhead, while still allowing country-specific variants where statutory year-ends genuinely differ. For Asset Accounting, the depreciation run must complete for a period before that period is locked in FI for asset-relevant account types, so I'd sequence closing tasks: run depreciation first, validate no errors, then close the prior period specifically for asset account types while potentially keeping other account types open longer for adjustments. Where a country needs a different fiscal year variant via a non-leading ledger, I'd ensure the ledger-specific posting period control is genuinely independent so its closing calendar isn't blocked by the leading ledger's period lock. Key architecture decisions: minimize variant proliferation for maintainability, sequence Asset Accounting closing before the FI period lock, and use ledger-specific period control where fiscal years genuinely diverge.
hardGeneral Ledger

68. In a multi-ledger S/4HANA landscape, walk through how you would maintain GL master data consistency when introducing a new non-leading ledger with a different fiscal year variant, and explain the CO integration implications.

GL account master data is maintained at chart-of-accounts and company code level, independent of ledgers, so the account itself doesn't change per ledger. However, when adding a non-leading ledger with a different fiscal year variant, you must assign the ledger to the relevant company codes via ledger-to-company-code assignment and ensure parallel currency/valuation settings align. CO integration is affected because cost elements derive from P&L accounts; postings must be replicated correctly across ledgers so CO objects (cost centers, internal orders) reconcile consistently. Special attention is needed for period-end allocations, since CO postings follow the leading ledger's fiscal year variant unless ledger-specific document types route differently.

Related lesson

General Ledger Foundations: Purpose, Organizational Structure and Master Data Map

Related topics

Accounts PayableAccounts Receivable

Next practice step

Practice with Interview AITake a mock test