The Accounts Payable (AP) and Accounts Receivable (AR) modules function as sub-ledgers to the General Ledger, managing all financial transactions with vendors and customers, respectively. Proper configuration of these areas is vital for effective cash flow management, automated payment processing, and proactive credit control. These settings govern the master data and transactional processes that are foundational to the procure-to-pay and order-to-cash cycles.

4.1 Accounts Payable (AP)

4.1.1 Defining Vendor Account Groups

Vendor Account Groups are used to classify vendors and control the configuration of their master records. Each group determines key settings such as the vendor number range (internal or external assignment), the field status for master data screens (which fields are required, optional, or suppressed), and whether the account group is designated for one-time vendors.

Vendor Account Groups are created using Transaction Code OBD3.

4.1.2 Creating a Vendor Master Record

A vendor master record contains all the necessary information for transacting with a vendor. It is created using Transaction Code FK01 and is structured into several logical data sections.

• General Data: This section includes information that is consistent across all company codes, such as the vendor’s legal Name, a Search Term for easy lookup, and official Address details.
• Company Code Data: This section contains data specific to a particular company code, including the Reconciliation Account in the G/L, the Cash Management Group for liquidity planning, and the agreed Payment Terms.
• Bank Details: This section stores the vendor’s bank account information, which is essential for processing payments.

4.1.3 Configuring the Automatic Payment Program (APP)

The Automatic Payment Program (APP), configured via Transaction Code FBZP, is a powerful tool used to automate the process of paying vendors. It analyzes open vendor invoices, identifies those that are due for payment, and generates the payment media (e.g., checks, bank transfer files).

The configuration of APP follows a logical hierarchy. First, you define the participants (which company codes will pay). Next, you define the rules of payment (methods available in each country and company). Finally, you define the instruments (which house banks and accounts will be used for which payment method). This structured approach ensures a robust and controlled payment process.

1. Setup All Company Codes: Define the sending and paying company codes that will participate in the payment run.
2. Setup Paying Company Codes: Set rules for the paying company code, such as the minimum amounts for incoming and outgoing payments.
3. Payment Method in Country: Define the available payment methods for each country, such as checks or electronic bank transfers.
4. Payment Method in Company Code: Assign the defined payment methods to specific company codes and set parameters like minimum and maximum payment amounts.
5. Bank Determination: Link the payment methods to the company’s specific bank accounts (House Banks) from which payments will be made.
6. House Banks: Configure the master data for the company’s own bank accounts.

4.2 Accounts Receivable (AR)

4.2.1 Defining Customer Account Groups

Similar to Vendor Account Groups, Customer Account Groups classify customers and control the configuration of their master records. They dictate the customer number range, the field status of master data screens, and other control parameters.

Examples of customer account groups include:

• X001 – Domestic Customers
• X002 – Export Customers
• X003 – One Time Customers

The creation process is managed through the SPRO menu path for defining customer account groups.

4.2.2 Creating a Customer Master Record

The customer master record centralizes all data required for processing sales orders, deliveries, invoices, and payments. It is created using Transaction Code FD01 and organized into the following sections:

• General Data: Includes information applicable across the entire organization, such as the customer’s Name, Search Term, and Address.
• Company Code Data: Contains accounting-specific information, such as the G/L Reconciliation Account and settings for Payment Transactions including Payment Terms and Tolerance Group.
• Credit Management: To maintain a customer’s credit limit, Transaction Code FD32 is used. This allows a credit controller to set and monitor the customer’s overall credit exposure.

4.2.3 Dunning Configuration

The Dunning system in SAP is used to automatically manage overdue receivables. It systematically reminds customers of their outstanding payments by generating dunning letters based on predefined rules. Key configuration concepts include defining Dunning Keys, which control the dunning level and text on the notice, and Block Reasons, which can be used to exclude a customer or an invoice from the dunning run.

With the core FI sub-ledgers configured, the manual will now shift from Financial Accounting to the configuration of core Controlling (CO) objects, which are essential for internal management reporting and analysis.