Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
GR /IR AP Process
Transcript of GR /IR AP Process
Goods Receipt - Invoice Receipt
Describe the correct way that GI/IR process should be performed in order to ensure quality of bookings and to comply with financial requirements
A GR/IR (goods-receipt/invoice-receipt) clearing account is a bookkeeping device that can be used when goods arrive before the invoice is generated, or when an invoice arrives before the goods are delivered.
The GR/IR clearing account checks the quantity of goods received against the quantity of goods invoiced and then posts a positive or negative balance accordingl
PO´s Life Cycle:
Create Purchase Order
To buy materials/ Goods
Perform reconciliation PO vs GR/IR
Pay to Vendor
In order to understand how GR/IR process works, we have to know the main concepts that integrate it.
Variables or Situations when we do the comparasion
Quantity GR = Quantity IR
Amount GR = Amount IR
Note: SAP has a tolerance limit set up where the invoice will be posted automatically
Quantity GR = Quantity IR
Amount GR X Amount IR
Price too High
Price Too Low*
Routed to PO creator
If there is a price difference between the invoice and the PO and the amount is less than the tolerance limit set up in SAP, AP is allowed to post the invoice.
If the difference is above the tolerance limit set up in SAP then it is routed to PO creator for clarification/approval
Quantity GR X Quantity IR
Amount GR X Amount IR
In the case where no GR and GR is required (marked in SAP), the invoice will be automatically blocked for payment until GR is done in SAP.
In case where no GR and is not required (not marked in SAP) AP will keep item in inbox until has been done and if needed to email Purchaser and remind about performing GR.
Posting Key / Document Types
It is a SAP code use to indicate if the accounting entry refers to Debit or a Credit and it depends on posted document type
It refers to Document Type e.g. Invoice, Credit note, Payment.
It refers to Document Type e.g. Invoice, Credit note, Payment.
The posting keys used often by Account Payable are:
It is the account where belongs the account entry register
PURCHASE ORDER HISTORY
Header Purchase Order
PO Analysis and Discrepancies
One way of investigate and analyze discrepancies between PO and Invoice is enter to transaction ME23N in SAP to check the PO.
In this transaction we can review different information than help us to investigate and find the solution to further processing.
This transaction is integrated by three principal sections:
HEADER - ITEM OVERVIEW - ITEM DETAIL
Note: Company code It´s a sensitive data that we cannot change in the workflow, for this reason it´s important to ensure that is correct before be registered, otherwise we have to delete and reprocess the document and this implies a cost for the service center.
Delivery / Invoice
We can check the Payment terms and currency
Vendors involve in the PO
One of the steps that we have to perform in this section, it´s validates measuring units: Pounds (LBS) to Kilograms (KG). The conversion factor that we use is 0.4536.
“X” LBS * 0.4536 =
2,000,000 LBS * 0.4536 = 907,200 KG
NOTE: All Purchase Orders are provisioned using NET WEIGHT
Here we can check if discrepancy between invoice and goods receipt is in the tolerance limit set up in SAP.
NOTE: It is important to mention, that if this option is marked in a PO, in case there are subsequent debits like Freight expenses; they will not be able to be registered, until the GR has been entered in SAP.
Inv Receipt" is checked indicating that besides the GR must be generated in SAP, the bill also must have been received, so that the document can be processed for payment.
This section is especially important to Freight because here we can review whom is going to present the Freight Invoice.
In this section we can start with the analysis in case that exits a discrepancy. But first we have to identify the document types in order to perform the reconciliation in the correct way
Subsequent debits are additional expenses, related to the material or services received that no were included in the Purchase Order. These expenses are freight and custom duties.
Subsequent debits will affect the Purchase Order History in amount not in quantity.
1) We never have to record a material invoice as subsequent debit.
In the case we found an extra invoice without PO, we have to analyze which one can be the reason before to record it again.
We can found in the analysis two main causes:
a) Provision was lower than real expense
b) Supplier sends twice the same invoice. In this case, the first step is the analyst should review the invoice reference in order to verify that is not a duplicate. And also can request a clarification to PO´s creator
2. Subsequent debits only must affect the Product Price Variance (PPV) account and the Profit center cost (PC). GR/IR should not be generated.
SUBSEQUENT DEBITS TYPES
Subsequent Debit Ledger :
Is an expense not accrued in a Purchase Order, generally freight expenses.
Subsequent Debit Deliver
: Is an expense not accrued from a provision/condition of freight
SUBSEQUENT DEBITS VARIANTS
A) When there is one line item o there are many line items from the same material
B) When there are many line items and are from different material a ratio between the monetary value and quantity of each line item is made.
C). An additional expense of spending not accrue
Incoming invoice with incorrect amount, generating discrepancies between GR/IR
The amount before taxes perfectly matched the GR , before processing the bill is owed to ask the plant controller or the buyer over the amount to which the invoice will post with the correct amount and keep this item is displayed in the report IR GR
Incoming credit note with incorrect amount
Credit note amount:
The credit note had to mess with number 15 instead of 14,999 and then ask the GR processor that will reverse that line of GR or ask the plant controller approval to run a ACCM
In these case if approval adjust PO through AccM
Quantities of posting invoices are entered wrong, and various corrections were also made to the lines of GR by the GR processor
To adjust this OP had to perform various reclassifications same could be avoided if the amounts had been entered correctly from the beginning of the process
A PO various delivery notes , for which invoices were not properly addressed , these were posted in the right direction but in a delivery note was inappropriate , generating various discrepancies
Through an analysis found that the invoices were loaded wrong
you ask the plant controller approval to run a fit and well clean this PO
A duplicate invoice is entered
As can be seen already had reversed a document and PO was adjusted , however the document 5102680031 was admitted and is causing the discrepancy in the PO , below are the two bills which reflected the same information
By contacting the plant controller confirmed that the bill was duplicated, this case is currently being reviewed by the same to obtain a credit note to adjust this PO
General Tolerance Limits
When processing an invoice, the System checks each item for variances between the invoice and the purchase order or goods receipt. The different types of variances are defined in tolerance keys.
The system uses the following tolerance keys to check for variances and the tolerance limits for each tolerance key for each company code:
AN: Amount for item without order reference
AP: Amount for item with order reference
BD: Form small differences automatically
B1:Order Price Quantity variance (GR) E/MSG
B2: Order Price Quantity variance (GR) W/MSG
BR: Percentage OPUn variance (IR before GR)
BW: Percentage OPUn variance (GR before IR)
DQ: Exceed amount: quantity variance
DW: Quantity variance when GR quantity = zero
KW: Variance from condition value
LA: Amount of blanket purchase order
LD: Blanket purchase order time limit exceeded
PE: Price variance: purchasing
PP: Price variance
PS: Price variance: estimated price
SE: Max. Cash. disc. deduction (purchasing)
ST: Date variance (value x days)
VP: Moving average price variance
Tolerance groups for company code
AN: The system checks every line item in an invoice with no order reference against the absolute upper limit defined
AP: The system checks specific line items in an invoice with order reference against the absolute upper limit defined. Which invoice items are checked depends on how you configure the item amount check
B1: 50% variance in order price
B2: 20% variance in order price
BD:The system checks the balance of the invoice against the absolute upper limit defined. If the upper limit is not exceeded, the system automatically creates a posting line called Expense/Income from Small Differences, making the balance zero and allowing the system to post the document
BR: The system calculates the percentage variance between the following ratios: quantity invoiced in order price quantity units : quantity invoiced in order units and quantity ordered in order price quantity units : quantity ordered in order units. The system compares the variance with the upper and lower percentage tolerance limits
BW:The system calculates the percentage variance between the following ratios: quantity invoiced in order price quantity units: quantity invoiced in order units and goods receipt quantity in order price quantity units : goods receipt quantity in order units. The system compares the variance with the upper and lower percentage limits defined
DQ: "If a goods receipt has been defined for an order item and a goods receipt has already been posted, the system multiplies the net order price by (quantity invoiced - (total quantity delivered - total quantity invoiced)).
If no goods receipt has been defined, the system multiplies the net order price by (quantity invoiced - (quantity ordered - total quantity invoiced)).
The system compares the outcome with the absolute upper and lower limits defined.
This allows relatively high quantity variances for invoice items for small amounts, but only small quantity variances for invoice items for larger amounts.
You can also configure percentage limits for the quantity variance check. In this case, the system calculates the percentage variance from the expected quantity, irrespective of the order price, and compares the outcome with the percentage limits configured.
The system also carries out a quantity variance check for planned delivery costs"
DW: If a goods receipt is defined for an order item but none has as yet been posted, the system multiplies the net order price by (quantity invoiced + total quantity invoiced so far).
The system then compares the outcome with the absolute upper tolerance limit defined.
If you have not maintained tolerance key DW for your company code, the system blocks an invoice for which no goods receipt has been posted yet. If you want to prevent this block, then set the tolerance limits for your company code for tolerance key BW to Do not check"
KW: The system calculates the amount by which each delivery costs item varies from the product of quantity invoiced * planned delivery costs/ planned quantity. It compares the variance with the upper and lower limits defined (absolute limits and percentage limits)
LA: The system calculates the sum of the value invoiced so far for the order item and the value of the current invoice and compares it with the value limit of the purchase order. It then compares the difference with the upper percentage and absolute tolerances defined
LD: The system determines the number of days by which the invoice is outside the planned time interval. If the posting date of the invoice is before the validity period, the system calculates the number of days between the posting date and the start of the validity period. If the posting date of the invoice is after the validity period, the system calculates the number of days between the posting date and the end of the validity period. The system compares the number of days with the with the absolute upper limit defined
PP: The system determines by how much each invoice item varies from the product of quantity invoiced * order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).
When posting a subsequent debit/credit, the system first checks if a price check has been defined for subsequent debits/credits. If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product of the quantity to be debited/credited * order price and compares this with the upper and lower tolerance limits (absolute limits and percentage limits)
PS: If the price in an order item is marked as an estimated price, for this item, the system calculates the difference between the invoice value and the product of quantity invoiced * order price and compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).
When posting a subsequent debit/credit, the system first checks whether a price check has been defined for subsequent debits/credits, If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product quantity to be debited/credited * order price. It then compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits)
ST: The system calculates for each item the product of amount * (scheduled delivery date - date invoice entered) and compares this product with the absolute upper limit defined. This allows relatively high schedule variances for invoice items for small amounts, but only small schedule variances for invoice items for large amounts
VP: When a stock posting line is created as a result of an invoice item, the system calculates the new moving average price that results from the posting. It compares the percentage variance of the new moving average price to the old price using the percentage tolerance limits defined
Now that you have the main concepts about elements that integrate the reconciliation of GR/IR. Please answer these questions in order to evaluate your knowledge.
1. In case that in the GR/IR reconciliation account there are Document Types WE not reconciled, which one could be the reason(s)?
2. In case that in the GR/IR reconciliation account there are Document Types RE not reconciled, which one could be the reason (s)?
3. When there is a subsequent debit where do you register it?
4. Which Document Type is used as account maintenance?
5. In which case do you need to use the account maintenance?