Utilizing Contract Account

Objective

After completing this lesson, you will be able to identify the purposeand usage of the contract account.

Contract Account – Introduction

A sequence showing 1. basic data, 2 scheduling, 3 technical master data, 4 business master data, 5. move-in, with distinct relations between each step.

You now need to create contract accounts for the new contract partners. This will enable you to create contracts for different divisions when the contract partners move in. The contract partner requires two contract accounts because the shared electricity and water costs are allocated to the first premise. By assigning two contract accounts to the contract partner, you enable the contract partner to use two different bank accounts, one for the shared costs and one for her own costs.

A summary of contract accounts: combining all business partner contracts, managed using open items accounting, and containing the control data for the payments transactions.
  • In the case of a residential customer, for example, you could group their gas, electricity and water contracts together in one contract account if all these contracts share the same dunning data and payment data (such as bank details).
  • You use this component to make basic settings for master data and to post and edit documents. The component also allows you to create and edit master data and post and edit documents manually.
A simple flowchart depicting a business partner with multiple contract accounts.

The business partner may have one contract account for energy consumption as a private individual and one contract account for her company's energy consumption, for example.

A pie chart showing data such as payment terms, interest key, individual dunning control within a segment labeled Contract account level, and creditworthiness contained in a segment labeled Business partner level.
  • Certain payment-relevant data is not managed on the contract account level but on the business partner level. A business partner has certain creditworthiness class that applies for all his/her contract accounts. Creditworthiness is therefore maintained on the business partner level.
  • Automatic creditworthiness is calculated in returns, dunning processes, write-offs, later payment charges and influences the activities of these accounting transactions. You can also override the creditworthiness manually.
A diagram of a contract account receiving data of different kinds, such as general data and dunning/payment data.

Dunning control is enabled via dunning procedure or collections strategy.

Each contract account is assigned to a contract account category, and its features determine whether the account can have one or more business partners or contract, whether it's a collective billing account, what the valid number range is, which screens and data fields can be used to process the account.

Contract account categories are configured in Customizing:

SAP Fiori app. On Home page→User Profile icon→App Finder→SAP Menu→Search in SAP Menu→Customizing – Execute Project→SAP Reference IMG→Financial Accounting→Contract Accounts Receivable and Payable→Basic Functions→Contract Accounts→Number Ranges and Contract Account Categories

General Data

Summary of key financial attributes and classifications for cash management, payment processing, and account identification, paired with a symbolic document icon.
  • Clearing category: Key that references the contract account in automatic clearing postings. It is combined with the clearing type to form the key that defines the clearing rules in Contract Accounts Receivable and Payable.
  • Account determination ID: Characteristic that is combined with the company code, division, main transaction, and sub-transaction (if applicable) for use in determining a G/L account.
Illustration showing how an incoming payment is processed based on a tolerance limit, determining whether the receivable is fully cleared or leaves a remaining balance.
  • Using the tolerance groups entered in the contract account, you can define and use tolerance limits for incoming payments.
  • If the incoming payment is less than the open items, the difference is within the tolerance span specified for the tolerance group for the contract account, and write-off of the difference is activated in clearing control, the receivable is cleared fully and a difference posting is created.
Illustration showing how one contract account is settled using another, emphasizing interconnected payment processes and shared financial responsibility between accounts.
  • If you specify a second contract account for one business partner, then the open items of both accounts are paid together.
  • The data that is required for payment or collection (for example, payment method, bank details, blocking reason, alternate payer) is taken only from the contract account that is used for settlement.
  • The settlement of the contract accounts is initiated by the payment program. The selections made in the parameters for the payment program determine whether a contract account is to be settled. Settlement occurs only if the business partner field is selected, or if neither the business partner field nor the contract account field is selected.
A flowchart illustrating a structured process for determining interest keys, prioritizing inputs like items and accounts, and applying rules for interest calculation and posting.
  • All control parameters for interest charge calculation (including parameters for selecting items on which interest is to be charged, or references to the relevant calculation rule, for example) are stored in the interest key.
  • Priorities for determining the interest key:
    • An interest key entry in the item itself has the highest priority. The interest key can be entered in the item manually or at the time of posting. The interest key is determined from SAP S/4HANA Utilities and FI-CA transactions.
    • If interest is charged on an item in the context of the dunning procedure, an interest key can be defined in the dunning level.
    • The interest key can also be stored in the contract account.
  • Interest can only be charged if the system can find an appropriate interest key.
  • The interest calculation rule is used to determine the correct rates of interest. You can also define any other relevant conditions here.
  • Interest rates are dependent on:
    • Reference interest rates (optional)
    • the analysis period
Visualizes a collective billing structure where individual accounts are linked to a central collector account for streamlined management and organization.
  • A contract account with contract account type collective bill must exist. Further contract accounts can be assigned to this collective bill.
  • Enter the corresponding collective bill account in the field Coll. bill acct of the other contract accounts. All the posting records of this contract account or other contract accounts involved in this collective bill account are recorded as statistical document items and calculated together. You get a collective bill listing the individual contract accounts. The G/L-relevant postings take place at individual account level.
Illustration demonstrating how individual and grouped contract accounts aggregate into bills, highlighting options for collective billing and account-specific totals.
  • If you want to generate a collective bill for several contract accounts, you must group these contract accounts together in a collective bill account. All posting records of these contract accounts are written to the collective bill account as statistical line items and are settled together.
  • If a collective bill account is specified in a contract account, the payment and dunning procedures specified for this account are suppressed. It is only processed with the corresponding collective bill account (with regard to the graphics, this means that the payment and dunning data of the collective bill account VSK 1 are valid for contract accounts 2 and 3).
  • Example: A property management company is to be billed for the water consumption of all its tenants. For this reason, you must create a contract account for each apartment. You must also specify collective bill account as the contract account for the property management company, and allocate this collective bill account to the contract accounts of the individual apartments.
Overview of collective invoice processes with a collaborative team discussion, highlighting automatic adjustments and management through transaction FPCB.
  • A maximum of 500 documents can be grouped in a collective invoice. The number of document items in the individual documents is irrelevant.
  • First bullet does not apply if Due Date Synchronization functionality is active.
  • Transaction Edit Collective Bill (Process Collective Bill Account) can be used to manage postings.
Overview of payment terms linking contract accounts to incoming and outgoing payment schedules, highlighting due dates, cash discounts, and payment term classifications.
  • A payment term is a key that determines the due dates for incoming payments (due date for net payment and, if applicable, cash discount, and cash discount deadline), and the deadlines for outgoing payments.
  • This key is stored in the contract account. In SAP S/4HANA Utilities, it is used to determine the bill due dates, and the budget billing due dates.
Illustrates how account classification aids supply area management, facilitates statistical analysis like consumption trends, and supports operational workflows.
Explains how clearing categories and types combine to define financial settlement variants, linking accounts and transactions to allocate amounts to open items in FI-CA.
  • Clearing category: Key that references the contract account in automatic clearing postings. The clearing category and the clearing type together form the key that defines the clearing rules in contract accounts receivable and/or payable (FI-CA).
  • Clearing type: Key that references the business transaction in automatic clearing postings. It is used in FI-CA to determine payment allocation rules and clearing rules.
  • Clearing variant: Key under which rules for automatically allocating open items for clearing postings are stored.
A visual representation of gas billing workflow, connecting company codes, divisions, account determination, and processes to determine debit and credit for residential billing.
  • The account determination ID, together with the company code, division, main transaction, and sub-transaction (if applicable), determines the revenue and receivable G/L accounts for a posting.
  • The account determination ID is determined automatically from the contract account, or from the contract, if a contract reference is specified in the document line item.
Illustrates how account determination connects contract details, business transactions, and receivables to assign the appropriate balance account in an energy supply context.
Illustration of revenue account determination process, linking business transactions and contract accounts to specific sales revenue accounts using transaction and account logic.

You branch to the value-added tax indicator via the revenue account. This gives the level of value-added tax.

Overview of budget billing methods by country, highlighting statistical approaches, debit entries, payment schemes, average monthly billing, and budget billing systems. Euro bag icon.
  • The payment scheme is designed to deal with the special requirements regarding the payment of value-added tax in Great Britain.
  • The payment scheme is a budget billing procedure that transfers the billed amount from the last consumption billing to the budget billing plan.
Comparison of statistical and debit entry procedures for budget billing plans, highlighting differences in displaying amounts as statistical or real items in account balances.
  • Statistical procedure: The system generates the budget billing plan during invoicing. When the budget billing amount is paid, it is converted into a real item and value-added tax then has to be paid (actual controlling). The invoicing component then automatically clears the budget billing amounts that have already been paid with the invoice sum total.
  • Debit entry procedure: The budget billing items are instantly converted into real items via partial billings. Payment of the budget billing amount only affects the clearing of the open item. They are not taken into account during invoicing.
Overview of North American payment plans highlighting average monthly billing and budget billing programs that simplify and standardize monthly utility costs for consumers.
Comparison of two billing calculation methods, showing AMB as a single average value and BBP as monthly averages with additional complexity. Both apply to U.S. and Canadian contexts.
  • AMB Procedure (Average Monthly Billing): In a AMB procedure, the customer pays an average amount every month. The amount is calculated from the last n months (generally 11 months). The AMB amount can differ from month to month.The balance forward becomes smaller as the end of the period approaches. The amount to be paid at the end of the period is generally less for customers using a AMB procedures than for those using BBP procedures. At the end of the period, the customer has to pay the AMB amount and the forward balance.
  • BBP Procedure (Budget Billing): In a BBP procedure, the customer pays an average amount every month. The amount is calculated from the last n months (generally 11 months). The remaining amount the customer has to pay at the end of the period (balance forward) is generally higher in BBP procedures than in AMB procedures. At the end of the period, the customer has to pay the BBP amount and the forward balance. In a BBP procedure, the BBP amounts are managed technically in a budget billing plan. However, these amounts cannot be viewed in the account balance display. They are stored in a shadow table. This table is used for the debit entry procedure.

Dunning and Payment Data

Summary of key considerations for managing dunning and payment data, emphasizing recipient, procedures, grouping, payee details, payment methods, and risk alerts for financial processes.
  • Dunning procedure: Defined procedure that determines how dunning takes place for business partners. The procedure determines details such as the following:

    • Number of dunning levels

    • Dunning frequency

    • Amount limits

    • Dunning texts

  • Dunning grouping type: Key representing criteria according to which items due for dunning are grouped when the dunning run is executed.
  • Collections strategy: grouping mechanism and entry point for determination of collections activities via Business Rules Framework Plus (BRF+). The strategy and business rules enable flexible, intuitive rule definition.
  • The standard company code controls postings where the company is not determined, for example, manual postings without reference to contract.
  • The Company code group enables you to define the allowable company codes for posting to this contract account.
Display control for: Business partner; Alternative bill recipients; Alternative dunning recipients.

Dispatch control is used to ensure flexibility in batch processing, so that you can send a document in different ways and as many times as you require. Dispatch control contains the following information:

  • Send method (for example, letter, fax, or e-mail)
  • Number of copies
  • Archiving mode (1 = print only, 2 = print and archive, 3 = archive only)
  • RDI indicator ('X' = RDI spool, 'I' = RDI-IDOC, ' ' = no RDI, '*' = depends on SAPscript form).
Overview of the dunning process, linking account data to structured payment reminders, emphasizing thresholds, activities, timing, fees, and interest for overdue payments.

To create a new dunning procedure, you must perform the following activities:

  • Define dunning procedure
  • Define dunning levels for dunning procedure
  • Specify minimum/maximum amounts for the dunning levels
  • Specify the desired dunning activities for the dunning levels
Illustrates the process of determining collection steps based on strategy, integrating business rules, credit ratings, dunning history, and data to optimize account management.
  • In the classical dunning the dunning procedure assigned to each contract account determines the number of dunning levels and the respective dunning activity sequence. This determination of the next dunning level is mainly based on the days in arrears and the amount of debt.
  • Dunning by collection strategy is based on business rules that are evaluated at run-time. This allows for a flexible evaluation of a broad range of parameters. A collection strategy is assigned on master data level. Contract accounts (or contract) can be treated individually or can be grouped together for collections. The evaluation of the business rules within the strategy return the next collection step (and related activities) to be carried out. There is not necessarily a fixed sequence of steps to be carried out one after the other. It is the specific circumstance of an account that determines the next collection step. The data that can be evaluated in the rules engine include the dunning data, dunning history, credit risk data and many more (including customer-specific tables).
Illustration conveying company code relationships, showing how groups and standard codes link to contract accounts for posting and assignments in financial systems.
  • The company code group includes all company codes that are permitted for posting to a contract account. One company code group is assigned to every contract account. Company code groups can overlap. For example, group G1 can contain company codes 0001, 0002 and 0003, while group G2 can contain company codes 0001, 0003 and 0004.
  • One paying company code is assigned to each company code group. A paying company code is responsible for the payment transactions, and contains the house banks and payment methods. Several company code groups can contain the same paying company code. The paying company code does not have to be assigned to the company code group explicitly.
  • One standard company code is assigned to every contract account. The standard company code is used for postings made when no company code can be determined by other means (e.g. payments on account, miscellaneous charges which do not refer to a billing contract).
Illustrates the flow of financial processes, linking business partners to contract accounts, highlighting blocking tasks and outsourcing functions within payment systems.
  • In the contract account master record, there are process blocking fields for dunning, incoming payments, as well as outgoing payments. If you want to disconnect the installations belonging to a customer's account, then enter a block reason in this field. You can restrict the block to cover a certain period of time. Alternatively, you can set more than one block for each business transaction.
  • Additionally, you can set an outsorting check group in the contract account for invoicing. The outsorting check group determines which outsorting checks the system perfomrs during invoicing. You can allocate as many meter reading units to one portion as you like. You can also store a manual outsorting. Using the data in the Number of outsortings field, the system determines how many manual outsortings are valid for the contract account. When you enter a manual outsorting, the system proposes the corresponding value, which you can overwrite at any any time. After each billing (or invoicing), the register is set back by 1. As soon as the register reaches 0, the system removes the indicator for manual ousorting from the contract account.
Illustrates the menu path to undertake account changes.

Account changes: You can select change data by flagging fields.

Technical Settings

Overview of contract account field group settings in a task-level menu, detailing how attributes like hide, required, or display control the visibility and interaction of fields.
Graphic illustrating the process for activating planned business changes, emphasizing prerequisites, the central business partner role, and contract account integration.

Planned changes function is only valid for business partners when time-dependency is not activated.

Hint

With SAP S/4HANA Utilities usage, business partner changes no longer require activation.

The changes are stored directly.

Learning

SAP FacebookSAP YoutubeSAP LinkedIn