Utilizing Contract Account

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.

• 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.

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.

• 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.

Dunning control is enabled via dunning procedure or collections strategy.

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

• 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.

• 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.

• 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.

• 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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

• 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.

• 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.

• 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 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.

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).

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

• 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).

• 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).

• 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.

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

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