Prepayment 

Use

You use prepayment for vendors with whom you have built up good business relations over a longer period of time. This approach benefits both parties:

·        The vendor receives prompt payment after issuing an invoice.

·        As the ship-to party, you can make optimum use of payment targets, as the system pays the invoice independently of the corresponding goods receipt and the invoice check.

You should only use prepayment if you have built up a business relationship good enough to ensure that you are paid back any unauthorized prepayments.

The standard functions in logistics invoice verification are not affected by prepayment, as the only difference is that payment is performed at an earlier date. The system continues to perform standard functions (with restrictions) such as checks and FI postings (after goods receipt). For more information, see Constraints below.

For each company code, you can define in the vendor master whether prepayment is required, is possible, or is not permitted.

Prepayment has the following characteristics:

·        A vendor item is created and an invoice is paid, independently of the corresponding goods receipt and the invoice check.

·        Payment of an expense invoice is triggered when the invoice is entered.

·        The posting date of the invoice document is used as the posting date for the prepayment document.
You can use the SET_POSTING_DATE method in BAdI WRF_PREPAY_INVOICE to change the posting date, for example, to the current system date, or the posting date of the invoice document.

·        Relevant invoice amounts for prepayment of the invoice are transferred to Financial Accounting (SAP FI).

·        The prepaid invoice is checked at a later date.

An invoice reduction is still possible as the result of a check.

·        The inclusion of a clearing account for prepayment. The system clears this after invoice verification and the corresponding FI posting have been carried out.

Restrictions

Note the following technical constraints:

...

§         If you use prepayment with logistics invoice verification, the system can only determine approximate solutions for the following closing settlements:

·         Month-end closing

·         Year-end closing

·         Closing at profit center or segment level

The system does not take invoice items into account for prepayment, only the invoice header and taxes.

A breakdown by individual item is required for a specific statement, however. You can get round this constraint by manually reclassifying or clearing individual invoice items in the prepayment clearing account in consultation with your external auditor.

§         You must check customer-specific substitutions or validations in Financial Accounting or Controlling and adjust them if necessary.

§         There are no invoice items available for prepayment. The system does not derive a business area for vendor line items if business area balances are active. The business area must be entered manually.

§         If you use the new general ledger, the following constraint applies for the account assignment of the prepayment clearing items: Since no items are known for an entered invoice at the time of prepayment, only an approximate solution is possible. There are two account assignment options for profit centers:

·         The system posts prepayment clearing account postings to a dummy profit center. You define the dummy profit center in Customizing.

·         The system distributes the amount to be posted to the prepayment clearing account to all profit centers, weighted according to the purchase order item amount. The system determines profit centers from the purchase order items assigned to the invoice.
The system cannot avoid discrepancies or incorrect distribution of the values to profit centers (for example, if different profit centers are determined during invoice verification to those determined in prepayment).  They cannot be corrected.

The system cannot distribute follow-up costs (such as exchange rate differences, cash discounts, and so on) to the original CO objects by adjusting the profit and loss statement. The system does not support this function in the context of prepayment.

 

·        You cannot use prepayment in the following circumstances:

¡        For credit notes or subsequent credits (only for invoices)

¡        In connection with the American tax jurisdiction code

¡        In connection with import sales/purchase tax or acquisition tax

¡        For one-time vendors

¡        For invoices in which the cash discount base amount is not the same as the tax base amount

·        Depending on your Customizing settings, you can change the invoice amount, the taxes, the reference (because of the FI assignment), and the invoicing party for a prepaid invoice. In this way, you can change important header data even after the invoice has been saved and the prepayment document has been posted. In this case, the system creates a credit memo in the background with the old invoice values (the equivalent of canceling the original document) and also creates a prepayment document with the new invoice values.

Note that frequent changes to header data can produce a large number of FI documents, resulting in an unmanageable number of items in Accounts Payable Accounting. Discuss this with your external auditor in advance.

·        Invoice verification is not performed when prepayment is made. The system does not identify variances in the invoice compared with the purchase order or the goods receipt. When prepayment is used, the system does not set an automatic payment block in line with the tolerance limits that you set in Customizing.

·        The system updates the fields on the Payment tab page when a non-prepaid invoice is posted, for example, the payment conditions are read or a payment block is set. The updated data is only transferred to the invoice document for a prepaid invoice if the relevant field is allowed to be changed according to the Customizing settings.

·        If you subsequently change an invoice document manually in distributed systems (if data has been entered incorrectly, for example), the system cancels the prepayment document and creates a new one.

·        You cannot use prepayment with material ledgers. We recommend that you customize the system so prepayment is not allowed for company codes to which plants with active material ledger are assigned.

·        Exchange rate differences arise if the exchange rate in the logistics invoice document changes between prepayment and invoice posting.  When it posts the invoice, the system does not post exchange rate differences for prepayment. If exchange rate differences arise, the system posts them when it clears the open items on the prepayment clearing account.

·        There can be differences due to exchange rate rounding in local or foreign currency for postings at document level.  The system usually assigns the rounding differences to the vendor line item in logistics invoice verification. Due to prepayment, the vendor line item has already been posted in a separate document. Any differences in the local currency or document currency remain on the prepayment clearing account and must be written off using FI methods (such as clearing open items).

Prerequisites

·        Prepayment requires invoices that you enter using logistics invoice entry.

¡        In a background process

¡        Using BAPI BAPI_INCOMINGVOICE_SAVE or BAPI_INCOMINGINVOICE_PARK

¡        Using EDI

¡        Or by parking (preliminary entry of) incoming invoices.

·        The prepayment clearing account must be created in the local currency as a balance sheet account that, like the goods receipt/invoice receipt clearing account, only allows automatic postings and is stored in account determination.

The system must group and assign the open items during the clearing process. You must make sure that a suitable sort key is stored in the account master.  You can customize the system so that the reference key is transferred to the Assignment of Prepayment Allocation Item field. When the system clears open items, it groups and assigns them on the prepayment clearing account, according to the relevant MM invoice. 

·        MM invoice documents can only be prepaid if you have made company-code-specific Customizing settings for the main company code. You make settings to control prepayment in Customizing for logistics invoice verification, by choosing Incoming Invoice ® Prepayment ® Configure Control of Prepayment at Company Code Level.

The system only performs prepayment if your settings allow it for both the company code and the vendor.

·        To allow the system to post taxes during prepayment, you must enter the taxes in the header for each tax rate when you enter an invoice manually.

·        EDI invoices must contain the tax for each tax rate at IDoc header level.

If, for example, the IDoc contains invoice items for the tax rates 16% and 7%, the IDoc must contain a segment with the tax rate 16% and a segment with the tax rate 7%.

·        You must customize fields that you want to change subsequently in prepaid invoices, for example, the Invoice Amount, Tax, Reference (FI assignment) or the Invoicing Party. You do this in Customizing for logistics invoice verification, by choosing Incoming Invoice ® Prepayment ® Configure Field Control for Prepayment.

·        For invoice reduction, you must have activated Tax Reduction in Complaint Document. The system posts the taxes in the FI invoice reduction document - not in the FI invoice document.

Process Flow

The standard procedure for invoice verification with prepayment of an expense invoice involves the following steps:

...

       1.      Entering Invoices and posting the prepayment document

       2.      Paying the invoice in SAP Financial Accounting (SAP FI).

Invoice payment is a standard function in SAP FI. When an invoice is due, the system processes the open vendor item in SAP FI and expands it.

       3.      Posting Prepaid Logistics Invoices

The order in which invoice verification procedure takes place can vary: Payment of the invoice can take place in FI, or after prepaid logistics invoices have been posted.

Changes to a prepaid invoice document

The following section refers to canceling the prepayment document. What this means is explained below:

If the payment run has not yet been performed and a document cancellation is possible, the system cancels the prepayment document. Otherwise the system creates a credit memo for the amount in the prepayment document.

If the Customizing settings for prepayment allow field changes in invoice documents, you can change a specific field in an entered, prepaid invoice document. This Customizing setting means that the field in the invoice is ready for input. If this field can also be changed in the FI prepayment document, the system changes the existing prepayment document when it saves it. Otherwise, the system cancels the prepayment document and creates it again.

If the Customizing settings for prepayment do not allow fields to be changed, you must delete the logistics invoice and create it again. If you delete a prepaid invoice, the system also cancels the prepaid FI invoice.

Result

Depending on the Customizing settings, the system performs prepayment automatically by creating an additional posting document. The system creates open items on the vendor account as part of logistics invoice verification, and posts the payables with taxes before checking the corresponding invoices. The system stores the prepaid invoice with the relevant status, for example, Scheduled for Background Check or Parked in logistics invoice verification. You can further process the invoice in logistics invoice verification, however, only limited changes can be made to the header fields.