Invoicing Functions

Invoicing orders or budget billing plan items are grouped into invoicing units so that they can be jointly invoiced and displayed on a bill. A unit forms the basis of invoicing processes.

• A grouping proposal is automatically created.

• Grouping parameters in the contract and billing document control the grouping proposal.

• You can edit the grouping proposal in event R403.

Examples of an invoicing unit: The electricity and gas contracts of a contract account are periodically billed. A bill correction is entered in the electricity account. All three billing documents are grouped together to form an invoicing unit. A bill is created.

The budget billing items from the electricity and gas contract are requested on one bill. They are an invoicing unit.

Billing documents of selected contracts in a contract account are grouped to form invoicing units in order to create a suitable bill that includes as many of the customer's contracts as possible. For this purpose, contracts are divided into three distinctive groups:

• Contracts for which the documents must be invoiced jointly.

  The billings of these contracts must always appear together on one bill (for example, a residential customer's contracts for electricity, gas, and water). If a document has to be invoiced with other documents, a search for the corresponding billing documents of the other contracts is carried out. If no valid document is found, invoicing is stopped.

• Contracts for which the documents can be invoiced jointly.

  The documents of these contracts are also grouped together, if possible, with the documents that must be invoiced jointly.

• Contracts for which the documents must be invoiced separately.

The billing documents that qualify for joint invoicing are transferred to FI-CA in an accounting document. During this process, the data from the individual billing documents is summarized according to fixed FI-CA criteria and other, company-specific controls (such as account determination and transaction determination).

Joint Invoicing: Example 1

In the first example, contracts 1, 2, and 3 must always be billed together. As contract 2 has not been billed yet, the contracts are not invoiced.

The other two contracts can be invoiced. However, the customer receives two bills, as one of the contracts can only be invoiced exclusively.

Event R403 can be used to influence how the invoicing unit is formed.

Joint Invoicing: Example 2

In the second example, the billing documents for the contracts 1, 2, and 3 exist, which means that they can be invoiced jointly.

As there is also a billing document for the optional contract, it can also be included in the invoicing unit.

In either case, the exclusive contract has to be invoiced separately.

Event R403 can be used to influence how the invoicing unit is formed.

The terms of payment are also used by other standard components (for example, FI, SD).

A predefined payment condition that refers to a term of payment is entered in the contract account.

If other payment conditions should be used for different services, several contract accounts have to be created.

The terms of payment could depend on the following data: Posting date, document date, system date.

Maintain the payment conditions and terms of payment in the Financial Accounting Customizing menu under:

• Contract Accounts Receivable and Payable→Basic Functions→Postings and Documents→Document→Maintain Payment Conditions

• Accounts Receivable and Accounts Payable→Business Transactions→Incoming Invoices/Credit Memos→Maintain Terms of Payment

The due date of the bill is based on the general elements of due date determination.

Final bill amount (credit/receivable) forms the basis for due date determination.

The due date is determined in the event Document: Determine due date from payment condition (1330).

The bill due date is stored in all business partner items from the newly created posting documents and in the print document header.

For the budget billing request or partial bill creation, the due date is:

• Transferred from the budget billing plan

• Re-determined if the request is delayed

When a collective bill is created, the due date is copied from the individual bills.

Bill due date consist of net due date, cash discount percentage rate.

When consumption billing is invoiced, the balance of evaluated consumption values incl. tax minus paid budget billing amounts is the basis for due date determination. Account maintenance and creation of sub-items take place.

You can use a different due date determination in a user-specific function module for event 1330. In the case, the SAP function module is not executed.

The day entries (date limits) must be made in ascending order and cover the whole month.

You must propose a date type (basis date). Recommendation: Document date or date of entry. When you are maintaining several date limits, you can only use one date type for each term of payment.

Cash discount:

• Only single-level cash discount entry permitted .

• Calculated net due date cannot come before the cash discount due date.

Grouping bill due date and due date of the next budget billing amount

Only possible when invoicing consumption billing.

Prerequisites are:

• Bill Receivable

• The BB/Bill Due Dates field (ABRABS) must be active in the portion.

  1. Bill is due together with the next budget billing amount.
  2. Next budget billing amount is due together with the bill.

• Control of billing due date (table TE501):

  • Amount check
  • Interval check

Event: IS-U Invoicing: Budget billing clearing (R420): Due date determination by including budget billing due dates.

This grouping allows you to influence the bill due date for the last time in invoicing.

The following applies in the control table TE501:

• The due date can be adjusted separately for direct debit payers/cash payers

• Amount check: Final bill amount < upper limit

• Interval check: Number of days between bill due date and budget billing due date

If the due date of the next budget billing amount and the bill are grouped together, the budget billing amount is included in the print document as a line item and, as a result, becomes relevant for the final amount. This budget billing amount can no longer be requested, or a partial bill is not created for it.

When several contracts are invoiced and each of these have a budget billing plan, the due date is only adjusted if the fixed value 2 is maintained in the field ABRABS in all portions.

In invoicing, a payment method is determined based on the final bill amount according to specifications set in the contract account. The determined payment method is transferred to the print document header.

The invoicing posting documents, however, do not have a payment method so that they can be regulated together in a payment run with other open items for the contract account. The items are reinterpreted during the payment run.

If the final bill amount represents a receivable, invoicing tries to determine an incoming payment method.

In the contract account, you can enter the customers desired incoming payment method (such as automatic debit, credit card).

Amount limits in Customizing or incoming payment blocks that may have been set in the contract account, can also influence the determination of the appropriate incoming payment method.

An incoming payment block ensures that a direct debit payer is treated as a cash payer - for example, a payment method is not determined.

Determination of the outgoing payment method depends on several factors. When the system determines remaining credit during invoicing, the invoicing process tries to enter the suitable outgoing payment method in the print document. This is necessary because information on the repayment method is required at printing time. However, payment methods are not entered in the FI- CA document. The items are reinterpreted during the payment run.

You can enter the customer's desired outgoing payment methods in the contract account (such as postal transfer, or check).

There is a posting area in Customizing for invoicing, where you can define the priorities of the outgoing payment methods to be used for each company code (for example, postal transfer has a higher priority than check or bank transfer).

Amount limits in Customizing or outgoing payment blocks, that may have been set in the contract account, can also influence the determination of the appropriate outgoing payment method.

Determination of the outgoing payment method can also be influenced by a user exit, that is, event R430.

Using the settings in Customizing for FI-CA, the invoicing process determines the account (posting areas R000 and R001) and the corresponding general ledger accounts.

It also determines the value-added tax. The billing component transfers only net amounts. Value- added tax is determined using the posting area R001.

You can specify whether the tax rate is determined from the billing period or from the tax rate that is valid at the time of invoicing. If you choose to determine taxes based on the time of invoicing, you must also specify which date is to be used: the entry date, document date, or posting date.

In Italy, Spain, and Portugal, for example, the tax is determined on the basis of the billing date. In this type of tax determination, the billing line items are not prorated if there is a tax change.

The tax code for sales and purchases is defined by the tax determination code, the country (from table T001) and the date. The tax code for sales and purchases is also used by other standard components (such as FI, SD) and is defined in the Customizing menu of Financial Accounting under Financial Accounting Global Settings→Tax on Sales and Purchases→Calculation→Define Tax Code for Sales and Purchases.

The tax determination code is defined in the same way as the revenue account determination (posting area R001).

Rounding information is stored as print document line items in the print document and have the document line item type ROUND. You can define the rounding rules in the Financial Accounting Customizing menu under Contract Accounts Receivable and Payable→Basic Functions→Postings and Documents→Basic Settings→Define Rounding Rules for Currencies.

Currency rounding is mandatory in some countries due to the currency used in payment transactions (for example, 5 rappen rounding in Switzerland). This occurs at posting document or posting item level, is a one-off occurrence for each bill, is displayed on the bill and is executed according to rounding rules defined in contract accounts receivable and payable.

Rounding information is stored in the print document as print document line items with the document line item types ROUND (rounding amount current bill) and ROUNDO ( rounding amount from previous bill).

Activate the function in Customizing for SAP Utilities under Invoicing→Basic Settings→→→Define Basic Settings. You can define the rounding rules under Invoicing→Invoice Processing→Define Invoice Rounding Rules or Define Rounding Limits for Rounding Amount Carryforward.

Rounding is executed at rounding level; it is considered for the next bill (rounding amount carryforward), displayed in the account and on the bill, activated in invoicing Customizing and is executed according to predefined rounding rules. The rounding balance is cleared when a contract account is finally invoiced.