ERPClimb logoERPClimb

SAP FICO Accounts Receivable Interview Questions

Accounts Receivable comes up in SAP FICO interviews because it is one of the few areas where an interviewer can tell, in two questions, whether you have worked with the process or only read about it.

Accounts Receivable (AR) in SAP FI covers the management of customer accounts, invoices, payments, credit exposure, and dunning as a sub-ledger fully integrated with the General Ledger. This topic progresses from business purpose and master data through configuration, posting logic, integration with Sales and Distribution and Treasury, reconciliation and dispute handling, and the changes introduced by S/4HANA's Universal Journal and cloud deployment models.

This page carries 29 reviewed SAP FICO accounts receivable interview questions, each with a complete written answer and no sign-in required. The set breaks down into 5 foundational, 14 mid-level and 10 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.

The fastest way to use this page is to read the question, answer it yourself, and only then read the answer. The gap between your version and the written one is your actual revision list for accounts receivable.

29 Accounts Receivable questions with answers

easyAccounts Receivable

1. In SAP Business Partner architecture, how is a customer master created and what is the relationship between the Business Partner, Customer, and the underlying roles required for Order-to-Cash processing?

In S/4HANA, the Business Partner (BP) is the single entry point for creating both customer and vendor master data using the BP transaction with customer/vendor integration (CVI) active. A BP record requires at least a general BP role plus an FI Customer role (e.g., FLCU00/FLCU01) and, for SD-driven order-to-cash, a sales area-specific customer role. The BP category (person, organization, group) determines available fields. CVI synchronization tables link the BP number to the customer account number, ensuring FI and SD both reference the same underlying master record consistently.
easyAccounts Receivable

2. In S/4HANA, how is a customer created using the Business Partner (BP) model for Order-to-Cash, and how does the relationship between BP, Customer role, and the resulting general/company code/sales area data differ from the classic customer master approach used in ECC?

In S/4HANA, a customer is created through transaction BP by assigning a Customer role (e.g., FLCU00) to a Business Partner. This generates the general data, company code data (reconciliation account, payment terms, dunning procedure), and sales area data (pricing, shipping, billing) synchronized behind the scenes into the classic KNA1/KNB1/KNVV structures. Unlike ECC where XD01 directly created the customer master, S/4HANA mandates BP as the single point of entry; the customer/vendor integration (CVI) framework ensures every customer number has a corresponding BP, enforcing a unified master data model across FI, SD, and CRM.
easyAccounts Receivable

3. In S/4HANA, when a Customer is created using the Business Partner model to support Order-to-Cash, what is the relationship between the Business Partner, the Customer role, and the resulting general data, company code data, and sales area data, and which company code segment fields most directly drive AR accounting behavior?

The Business Partner is the master object; assigning it the FI Customer role and the Customer role for Sales creates the customer number and generates the three data levels: general data (address, communication, tax numbers) shared across the client, company code data (reconciliation account, payment terms, dunning procedure, tolerance group, interest indicator) controlling FI/AR posting and closing behavior, and sales area data (pricing, delivery, billing) driving SD processing. The reconciliation account field links the customer to the GL, payment terms and dunning procedure drive open item due dates and collections, and the tolerance group governs payment differences accepted automatically.
easyAccounts Receivable

4. A customer's sales order is blocked due to a credit limit check, and later that same day the customer's outstanding invoice is paid and posted as an incoming payment in FI during month-end close activities. As an entry-level consultant, how does this incoming payment posting affect the customer's credit exposure, and what would you check to confirm the sales order block is released?

Posting the incoming payment clears the open invoice, which reduces the customer's open receivables balance feeding into credit exposure calculation in SAP Credit Management (or classic FD32/FSCM depending on version). Once the invoice is cleared and credit exposure recalculates below the assigned credit limit, the previously blocked sales order should automatically re-check credit status and release, though this can depend on whether credit checks are re-triggered automatically or need manual re-release in SD (VKM3/VKM4). I would confirm the payment document cleared the correct customer open item, check the updated credit exposure via the credit management app or FD33, and verify the sales order credit status in SD.
easyAccounts Receivable

5. When a customer master is created using the Business Partner model in S/4HANA for Order-to-Cash, what are the key data levels (general data, company code data, sales area data) that must be maintained, and how do the company code segment fields specifically drive AR accounting behavior?

The BP is created with General Data (name, address, bank details, tax numbers) at client level, then extended with the Customer Company Code role which carries FI-relevant fields such as reconciliation account, payment terms, dunning procedure, and sort key. Separately, the Sales Area segment (maintained via customer role for SD) holds pricing, delivery, and billing data. AR postings depend on the company code segment: the reconciliation account link to the GL determines which GL account is updated, payment terms drive due date/discount calculation, and dunning procedure controls collections. Without both roles properly assigned, invoices cannot post correctly to FI or be billed via SD.
mediumAccounts Receivable

6. What standard reports or tools would you use to review a customer's dunning history and current dunning level, and how does an SD-driven credit or delivery block interact with the dunning process for that customer?

Dunning history and levels can be reviewed via the customer line item display and the dunning history stored against each open item, which shows the last dunning date, dunning level, and dunning procedure assigned on the customer master company code segment. The dunning program itself is run and monitored through the dunning proposal/run transactions where you can review the proposal log per customer before printing notices. An SD-driven credit or delivery block does not directly stop the dunning run, but a rising dunning level can feed into the customer's credit score or trigger a manual credit block, and conversely resolving overdue items through payment can help clear an existing SD block once the receivable is cleared.
mediumAccounts Receivable

7. What standard reports or tools would you use to analyze a customer's dunning history and current dunning levels, and how does an SD-driven credit or delivery block interact with the dunning process for that customer?

Dunning history can be reviewed through the customer's dunning data on the master record and dunning-related line item fields showing last dunned date and dunning level per open item, along with dunning run logs from the dunning proposal/run transactions. SD-driven blocks such as a credit block on a sales order are separate from the dunning procedure itself, but a customer with a high dunning level often also has a manually or automatically applied order/delivery block configured in the customer master or credit management settings, so operationally both processes reinforce collections pressure. I'd cross-check the customer's dunning level against any SD block flags to explain to sales why an order is being held despite dunning not being the direct trigger.
mediumAccounts Receivable

8. A customer makes a partial payment covering only part of one large overdue invoice, leaving the remaining balance open. During the next dunning run, the customer receives a dunning notice showing the full original invoice amount rather than the reduced open balance. How would you troubleshoot this?

I'd first check the open item itself in the customer line item display to confirm the partial payment posting actually reduced the invoice balance rather than being posted as a separate open credit item (which happens with partial payment method, since the original invoice stays open at full value while the partial payment sits as a separate open item). If partial payment was used instead of residual payment, the dunning letter design/text may be pulling the original invoice's gross amount rather than netting it against the linked partial payment. I'd review the dunning form logic and confirm whether partial payments are supposed to be shown net or reference both items, and correct dunning form configuration or reclassify the payment as residual if that better reflects business intent.
mediumAccounts Receivable

9. What standard SAP reports or tools would you use to build a portfolio-level dunning KPI view (e.g., dunning level distribution, total dunned amount by customer segment) across a large customer base, and how would you incorporate the SD credit/delivery block status into this reporting?

I would use the dunning history data available per customer (dunning level, dunning date, and amount stored on customer line items) combined with customer line item reports to aggregate open items by dunning level and total value, often exporting to a reporting layer or using a query on relevant tables for portfolio analysis. To incorporate SD block status, I'd cross-reference the customer's credit/delivery block indicators from the sales area data alongside AR dunning levels, since a customer at dunning level 3 with an active delivery block represents a higher-risk profile that collections and sales management should jointly monitor. This combined view helps prioritize collection efforts and informs whether blocked customers are being appropriately escalated.
mediumAccounts Receivable

10. A customer partially pays an overdue invoice, but the dunning run still sends a dunning letter for the full original invoice amount rather than the remaining open balance. How would you troubleshoot this?

First verify the partial payment was posted using the 'partial payment' function rather than residual payment, since partial payments leave the original invoice open in full while creating a separate payment line item, and dunning correctly considers the net open balance across both items in the account, not just the invoice line. Check if the dunning selection is somehow excluding the payment line item due to a dunning block or different dunning area/level assignment. Also confirm the account is being dunned at item level correctly and that the payment document wasn't blocked or excluded via a dunning key.
mediumAccounts Receivable

11. A customer down payment is posted using Special GL indicator F (request) then A (received), and later applied against the final invoice via F-39/clearing. The special GL account clears correctly in FI, but the corresponding house bank sub-account never shows the offsetting bank statement clearing, leaving an open item in the bank clearing account. How would you troubleshoot this integration issue?

First confirm the incoming payment was posted through the correct bank clearing account (not directly to the main bank GL) using the house bank/account ID configured in FBZP. Check EBS (electronic bank statement) posting rules and algorithm assignment in the bank determination config, since a wrong interpretation algorithm can misapply the amount to a different clearing account. Verify the payment method and house bank on the customer master and payment program parameters. Also check for manual postings bypassing F-28/FEBAN clearing logic, and reconcile BSEG entries against the bank sub-account line items.
mediumAccounts Receivable

12. What configuration approach would you use to govern changes to customer master fields (such as reconciliation account, payment terms, and dunning procedure) that directly impact the AR closing process, and how do sensitive-field controls, change document tracking, and mass-maintenance tools fit together?

Configuration typically combines field status controls at the account group level to determine which fields are mandatory or display-only, activation of change document logging (via the customer account group settings) so all master changes are captured in change documents, and authorization objects restricting who can maintain sensitive fields like reconciliation account or dunning procedure. For mass changes, tools like mass maintenance transactions or BP-based mass change functionality should route sensitive-field edits through a workflow approval step rather than direct update, especially near AR closing when reconciliation account changes could break GL/subledger tie-out. Regular review of change documents against an approved change list is a key closing control.
mediumAccounts Receivable

13. A customer makes a partial payment against an overdue invoice using incoming payment posting, creating a new residual open item for the unpaid balance. However, the next dunning run entirely skips this customer's invoice from the dunning proposal even though the residual balance is clearly overdue. How would you troubleshoot this?

I would first check the residual open item in FBL5N to confirm it carries the correct due date and is not accidentally marked with a dunning block or dispute indicator inherited from the original invoice. Next, I'd review the dunning procedure assigned on the customer master and the minimum days in arrears/minimum amount thresholds, since a small residual balance might fall below the dunning threshold. I'd also verify the item's dunning key and dunning block field weren't set during the partial payment posting, and check if a legal dispute or payment block was carried over from the original document, preventing the residual item from being selected in the dunning proposal.
mediumAccounts Receivable

14. A customer makes a partial payment against a single large overdue invoice using incoming payment processing (not residual), leaving the balance open on the same invoice line item. During the next dunning run, the collections team notices the dunning notice still shows the original full invoice amount instead of the reduced open balance, and the customer disputes the notice. As the FI consultant supporting collections, how would you investigate and correct this?

Since partial payment keeps the original open item and creates a separate payment line rather than reducing the invoice amount, the dunning notice correctly lists both items but must net them for the customer's true exposure. First check whether the dunning program's grouping/sorting is configured to display items per account and whether print form logic sums line items correctly. Verify the payment was actually cleared against the correct invoice reference and posting date, check FBL5N for open items, confirm dunning level/block settings, and review the dunning form's line-item layout in the correspondence configuration to ensure it nets partial payments against invoices rather than listing gross invoice value alone.
mediumAccounts Receivable

15. What standard reports or tools would you use to review open customer disputes and confirm whether disputed invoices are correctly excluded from the dunning proposal, and how do these dispute cases interact with the dunning block on the affected line items?

Use FSCM Dispute Management (UDM_DISPUTE) to review open dispute cases linked to specific invoices, and check the dunning block indicator on the disputed line item in the customer line item display (FBL5N). A dispute case typically triggers a dunning block automatically if configured via the dispute case processing linkage, so the disputed invoice is excluded from the next dunning proposal (F150) run. Confirm the dunning block reason code on BSEG-MANSP and cross-check dispute case status against invoice clearing status.
mediumAccounts Receivable

16. What governance controls should be configured for customer master data to ensure accurate AR closing, and how do dual-control mechanisms prevent unauthorized changes to sensitive fields?

AR closing accuracy depends on customer master governance including field status groups controlling mandatory/optional fields, sensitive field change logging (e.g., payment terms, bank details, dunning area) that triggers a block on subsequent payment runs until confirmed by a second user, and periodic reconciliation of the customer reconciliation account assignment. Change document logging (via table CDHDR/CDPOS) provides an audit trail. Segregation of duties ensures the requester of a master data change cannot also approve it, reducing fraud risk and ensuring closing balances reflect approved, validated customer data.
mediumAccounts Receivable

17. What key reports and dunning-relevant configuration on the customer master would you review to explain why a customer appears in the dunning proposal list but was excluded from the final dunning run?

First check the customer master's dunning procedure and dunning block field, since a block set after the dunning proposal was generated will exclude the account at the print/final run stage. Review the dunning history data on the customer to see if the last dunning date and level are within the configured minimum days between dunning notices. Also verify that no individual line items carry a dunning block or dispute case reference. Reports like the dunning list (proposal log) show excluded accounts with reason codes, helping confirm whether it's a master data block, item-level block, or interval timing issue.
mediumAccounts Receivable

18. What configuration approach would you use to govern changes to customer master fields such as the reconciliation account, payment terms, and dunning procedure so that unauthorized or unreviewed changes do not distort the AR closing process, and what tools support tracking these changes?

Configure sensitive fields via field status and authorization objects so changes to reconciliation account, payment terms, and dunning procedure require a separate approval or dual-control workflow rather than direct field-level edit by the same user who posts. Change document logging (activated at the field/table level for KNB1) captures who changed what and when, viewable through customer master change reports. Combine this with restricting reconciliation account changes to a controlled few via authorization group assignment on the GL account, and periodically audit changes right before month-end AR close to prevent last-minute reconciliation account swaps that would break GL-to-subledger tie-out.
mediumAccounts Receivable

19. How would you configure sensitive-field change governance for customer master data (such as payment terms, dunning procedure, or reconciliation account) to protect the integrity of the AR closing process?

Sensitive fields are defined so that changes trigger a confirmation/dual-control workflow before the record can be used for further postings, preventing a single user from both changing critical data and posting a transaction. This is combined with authorization objects restricting who can maintain company code segments of the customer master, and periodic change-log review using the master data change history. For AR closing specifically, reconciliation account changes should be tightly restricted since altering it retroactively affects GL account assignment reporting, and payment terms/dunning procedure changes should be reviewed before a dunning or aging run to avoid distorting close-period reporting.
hardAccounts Receivable

20. Walk through how a customer bill of exchange receivable is posted using a Special GL indicator, and how this integrates with bank accounting when the bill is later discounted or collected through the house bank.

The original invoice is posted normally to the customer reconciliation account. When the bill of exchange is received, it's posted with a Special GL indicator (e.g., 'W') which reduces the standard receivable and creates a special GL bill-of-exchange receivable, keeping it visible separately in reporting while it remains linked to the original open item. When the bill is discounted at the bank before maturity, a contingent liability posting is typically made along with a bank clearing entry reflecting proceeds net of discount charges; at maturity, the bank confirms actual collection via the electronic bank statement, which clears the special GL item and closes out the contingent liability. Discrepancies at collection (protest/dishonor) require manual reversal.
hardAccounts Receivable

21. Walk through how a customer bill of exchange receivable is posted using a Special GL indicator in AR, and explain how it integrates with bank accounting when the bill is later discounted or collected through the house bank.

The bill of exchange is posted against the customer using a Special GL indicator (e.g., W) that redirects the posting from the standard reconciliation account to a bill-of-exchange receivable GL account while keeping it linked to the original customer open item for reporting. When the bill is discounted with the bank before maturity, a contingent liability posting (often another Special GL transaction) is created to reflect the bank's recourse until the bill's maturity, and the house bank clearing account receives the discounted proceeds net of bank charges/interest. At maturity, when the bill is honored or collected, the special GL item is cleared, the contingent liability is reversed, and the actual bank account is updated through electronic bank statement or manual bank posting, tying the AR subledger back to bank accounting.
hardAccounts Receivable

22. In an Order-to-Cash scenario, a customer underpays an invoice due to a pricing dispute and AR posts this using residual payment. Explain how the residual open item's tax treatment integrates with the original SD billing document's tax code, and what happens when SD later issues a credit memo to resolve the dispute, from a tax reconciliation perspective.

The residual item created by the payment posting carries forward the same tax code and tax base proportionally reduced only if configured to recalculate tax on the residual; by default the residual item is simply the unpaid difference and does not automatically re-trigger tax recalculation, since the original invoice's tax was already posted and reported in the period it was created. When SD later issues a credit memo to formally resolve the dispute, that credit memo generates its own tax line reducing the previously reported output tax, which must reconcile with the residual item being cleared in FI. This means the AR team must ensure the residual item is cleared against the SD credit memo rather than left open, otherwise the VAT return may show a mismatch between invoiced and adjusted tax amounts for that period.
hardAccounts Receivable

23. Your organization operates centralized collections across multiple company codes, and customers frequently take unauthorized cash discounts on tax-relevant invoices when paying via lockbox. Standard incoming payment postings via cash discount clearing are creating small tax discrepancies between the original invoice tax amount and the discounted payment tax base, and this is surfacing in tax reconciliation reports at quarter-end. As the architect, how would you design a solution to handle this at scale?

First confirm whether the tax jurisdiction requires cash discount to proportionally reduce the tax base; if so, cash discount base amount configuration (OBB8/tax base for discount) must be set so the system recalculates tax on the discounted amount rather than leaving tax untouched. Where unauthorized deductions create genuine underpayments rather than valid discounts, use residual/partial payment logic instead of discount clearing so original tax remains intact on the open item. Standardize a payment difference tolerance and reason code framework centrally, and route exceptions above tolerance to collections for manual review rather than automatic discount posting.
hardAccounts Receivable

24. A customer pays an invoice slightly short of the full amount due to a disputed shipping charge, and this is posted using residual payment. Explain how the residual open item is created, how the tax originally posted on the invoice is treated, and what downstream tax reporting implications this raises.

Residual payment clears the original invoice in full and generates a new, smaller open item for the unpaid difference, typically posted with a new document date and its own due date/payment terms. The tax amount on the original invoice generally remains as originally posted and is not automatically recalculated on the residual item unless the residual item is configured to carry a proportional tax split; most configurations post the residual as a net amount without re-triggering output tax calculation. This means the tax reported to the authorities on the original invoice stays unchanged, but if the residual represents a genuine price/quantity adjustment rather than a timing dispute, a credit memo with tax adjustment may be more appropriate than a plain residual item, since residual payments don't automatically adjust output tax declarations.
hardAccounts Receivable

25. A customer pays an invoice short by a small amount citing a tax dispute, and you post this using residual payment. Explain how the residual item is created, how tax is handled, and what downstream reporting/tax implications arise.

During residual payment posting (e.g., via F-28), the original invoice is fully cleared and a new open item is created for the residual (underpaid) amount, typically inheriting the same tax code and terms unless manually adjusted. Since the residual item is a new receivable, it will appear as a new aging bucket starting from the payment posting date, not the original invoice date, which can misrepresent true aging unless baseline date is manually set. If tax was originally charged, the residual amount still carries a proportional tax component embedded in the line, so any subsequent write-off or dispute resolution must consider whether output tax adjustment is required.
hardAccounts Receivable

26. Walk through the end-to-end process of posting a customer security deposit or bank guarantee using a Special GL indicator against an outstanding invoice, and explain how its later release or forfeiture integrates with bank accounting when the guarantee funds are held at the house bank.

A customer bank guarantee is posted using a Special GL indicator (a noted item or statistical posting depending on configuration) referencing the customer account, without affecting the regular reconciliation account balance in AR aging. When the guarantee is called upon or released, a follow-up posting clears the special GL item and, if funds are drawn from the guarantee, an incoming payment is posted through the house bank, hitting the bank clearing account before reconciliation via bank statement processing. If the guarantee simply expires unused, the special GL item is reversed. Throughout, the special GL indicator ensures the guarantee exposure is visible separately from open trade receivables while still linked to the customer for credit and reporting purposes.
hardAccounts Receivable

27. A customer underpays a tax-relevant sales invoice due to a pricing dispute, and AR posts this using residual payment, generating a new residual open item for the shortfall. Walk through how the residual item is created, how the original tax amount posted on the invoice is treated on this new item, and what happens when SD later issues a credit memo to formally resolve the dispute, from a tax reconciliation standpoint.

Residual payment clears the original invoice fully and creates a brand-new open item for the unpaid difference, but this new residual item is a plain receivable line without its own recalculated tax code by default; the original invoice's tax was already posted and reported in that period, so the residual balance itself is not automatically tax-adjusted. When SD later issues a credit memo with the appropriate tax code to formally reduce the receivable and output tax liability, this creates a new posting that must be matched against the residual item, and the tax authority reporting requires reconciling the original invoice tax, the residual receivable, and the credit memo's tax reversal to avoid overstating output VAT.
hardAccounts Receivable

28. During AR year-end closing, your organization reclassifies a portfolio of aged customer receivables to a doubtful-debt GL account using a periodic reclassification posting run, but SAP Credit Management continues to include these reclassified receivables in open credit exposure calculations. As a result, unrelated healthy customers sharing the same credit group are unexpectedly blocked from new sales orders. As the architect, how would you diagnose and resolve this while maintaining GL/credit integration integrity?

First confirm whether the reclassification posting actually clears the original customer open items or only creates a statistical/reporting-only reallocation; if the original receivable line items remain open on the customer account, credit exposure calculations will still count them regardless of the GL reclassification. Check how credit exposure is derived, since it is typically driven by open FI-AR items and open SD documents, not directly by GL account grouping. Diagnose whether the reclassification run used a posting type that truly clears the original items or a value-only transfer, review credit segment/group assignment for the affected customers, and if needed adjust the write-off/reclassification process to clear the underlying open items so exposure recalculates correctly and unrelated customers in the same credit group are no longer impacted.
hardAccounts Receivable

29. In an Order-to-Cash scenario, a customer pays a down payment on a sales order before delivery, posted via Special GL indicator F/A. Credit Management (FD32 or UKM_BP) continues to show full open exposure for the underlying sales order as if no payment was received, causing new orders for the same customer to be blocked. As the architect, how would you diagnose and resolve this while maintaining GL/credit integration integrity?

Check whether the credit exposure category configuration includes special GL down payments as a reducing factor; by default, down payments posted with SGL indicator do not automatically net against open sales order value unless the credit horizon/exposure categories are explicitly configured to consider them. In classic Credit Management, review OB01/OVA8 exposure category settings; in S/4HANA, review UKM_BP risk category and FSCM credit exposure category mapping. Confirm the down payment update category is included in the credit exposure formula, and rebuild exposure via F.28 or UKM_BP simulation if needed.

Related lesson

Incoming Payment Processing and Automatic Clearing in Accounts Receivable

Related topics

General LedgerAccounts Payable

Next practice step

Practice with Interview AITake a mock test