Invoices with 3-Way Match in SAP MM-LIV

One challenge often faced in accounts payable is how to handle variances in the three way match when posting invoices. SAP has a very robust process for ensuring that invoices are matched against the PO and GR. In this three part series, first, we’ll review the business process and how SAP enables it. Second, we’ll discuss handling variances through posted invoices in MIRO. Third, we’ll discuss handling variances through parking invoices and MIR6.

Three Way Match with Invoices

A three way match is an accounting control that ensures that the purchase order, inventory receipt, and invoice all match in terms of product, quality, quantity and price.

  1. The process starts when purchasing creates an order and sends it to a vendor. The purchase order includes important information such as the materials, quantity, price, the location to ship to, tax information, and so forth.
  2. The vendor ships the product to plant specified on the purchase order. The plant staff print out a receipt form for the order. The receipt contains the vendor and the expected materials, but not the quantities  The quantities are entered onto the form. Additionally, the product is checked for damage, spillage, quality, and so forth.
  3. The vendor sends an invoice to the accounts payable department for the company. The invoice specifies the purchase order, the quantities, price, and total price for the shipped product.
  4. Accounts payable must now verify that the quantities on the PO match those of the receipt and invoice. Additionally, the prices must be checked between the PO and the invoice. Any variance must be researched and dealt with as a collaboration between procurement, the warehouse, and AP.

The three way match is one of the most important accounting controls as inventory is often one of the biggest assets that a company will have on their balance sheet. The control also ensures that inventory and other assets are properly obtained with the correct process.

Invoice process with purchase order, goods receipt, invoice receipt, and variance resolution


How does SAP enable a 3-way match for posting invoices??

SAP enables a similar process through purchase order (PO), goods receipt (GR), and invoice receipt (IR). Purchasing and goods receipt configuration are not in the scope of the article, but we’ll touch on those processes. The key for the process is to consider the quantities and price on the PO, GR, and IR. SAP will be verifying the quantities of these throughout the process.

Process of matching GR/IR in SAP for Invoices


In the above flow, the purchase order is issued to the vendor for a quantity of eight at a price of $12.50. The PO does not make any entries in accounting. When the goods are received, they’re always received at the PO price for the quantity counted by the receiver. That posts inventory and puts a credit on the GR/IR account. The GR/IR account is a kind of super clearing account in SAP that ensures the three way match.

So now, let’s look at the SAP screens. First, we have a purchase order:

Simple Purchase Order created using ME21N


(1)Posted with ME21N, displayed with ME23N

Next, we have the goods receipt. The GR will debit inventory and credit the GR/IR account.

GR against a PO posted via MIGO

(2)Posted with MIGO, displayed with MB03


Accounting Entry of the GR

Next, we have the invoice receipt that is posted through MIRO. Notice that the AP vendor is credited and the GR/IR is zero’d out with a debit.

Logistics Invoice posted through MIRO(3)Posted with MIRO and displayed with MIR4

Accounting Entry for LIV

And there we have it. In the next posts, we’ll discuss the challenges of detecting and resolving variances withe MIRO.





References   [ + ]

1. Posted with ME21N, displayed with ME23N
2. Posted with MIGO, displayed with MB03
3. Posted with MIRO and displayed with MIR4

By |October 27th, 2017|AP|0 Comments

Read More

Performing GL Conversions Correctly Part I

It amazes me that GL conversions go so wrong so often. The recipe is straightforward and if the legacy data is good enough, there is rarely an excuse to have trouble during GL conversions. Yet, I’ve seen quite a few go off track. So in this series of posts, I’d like to talk about the critical points to doing them correctly.

What we’re converting

In general, most GL conversions are done on a period by period basis to ensure that the trial balance, P&L, and balance sheet are correct for the periods in question. Usually line item detail is left behind in the legacy system. So at the end of the conversion process, I should have worksheets that tie out each new account balance drilled down to the relevant cost objects and profit center for each period.

Let’s suppose that we have a GL conversion from a legacy system to our SAP GL that is supposed to span three years of data – 2011, 2012, and 2013 (YTD). We cannot just start with 2011 though. The end balance sheet for 2010 must be loaded to ensure that the starting position is correct. The P&L for 2010 does not necessarily need to be loaded as long as retained earnings is loaded correctly.

The GL conversion process

GL Conversion Process (ETL)

The GL conversion process is usually done in three steps that follows the acronym ETL. First, the existing GL balances are extracted from the legacy system. The balances data is placed into a staging location. This location could be a simple as a flat text file on a file server or as complex as complete database system with a web front end.

Next, the data in the staging table is transformed from the legacy GL characteristics to the new SAP GL characteristics. This step is accomplished with mapping tables that take the legacy value onto the SAP value.  These mapping tables can become exceedingly complex if the logic is ugly.

Third, the transformed data is loaded into the new SAP system. This step is usually done with an LSMW that injects the standard GL posting program, but I’ve also seen other methods such as Idocs and recordings. At this point, all of the GL data should be loaded into the SAP system.

Key checks in a GL conversion

Throughout the GL conversion process, it’s important to ensure that each step succeeds. At the absolute bare minimum, when the data is loaded into the new SAP system, it’s critical to ensure that legacy balances match the new SAP balances per each costing object and period and in each relevant currency. It’s much better though to make checks throughout the process. Often times, a few heuristics will detect problems much earlier. A couple suggestions:

  1. Debits=Credits. If your trial balance doesn’t balance at each step, something is obviously wrong.
  2. P&L matches. The P&L should always match throughout the process. If it doesn’t, something went wrong.
  3. Assets, Liabilities, and Equities match. Each major class should
  4. All values mapped. Once the transformation step is complete, all accounts, company codes, cost objects, etc should be mapped. If any aren’t, the mapping table isn’t complete or there is a bug in the transform logic.

Finally, it’s incredibly important to ensure that the roll-up of the legacy accounts and cost objects matches that of the new SAP system. That means ensuring that an account that is mapped as an asset in the legacy system is still mapped as an asset in the new SAP system. Even more complicated, it means ensuring that a profit center in a management entity is mapped to the same management entity in the new SAP system. Usually the consolidations team will have a lot to say here.

Each mapping of GL accounts should preserve the account group

In our next installment of Performing GL Conversions Correctly, we’ll explore a standard journal entry flow and how to handle sub-ledger accounts.

By |September 29th, 2017|GL|0 Comments

Read More

Currency types in SAP FI

Understanding currency types in SAP FI is critical for both users and consultants. If a user does not understand the currency types, then they will book entries wrong. If the consultant does not understand them, then serious valuation problems can result.

Consider the following:

We have a Mexico affiliate of a US corporation that is procuring supplies from Germany. The contract is denominated for 500 EUR, but the company reports tax locally in MXN, and operating results from all countries are consolidated into USD. 

What currency should the contract be tracked in? The answer, of course, is EUR, MXN, and USD. SAP gives us the flexibility to account in different currencies for different purposes.

Currency Types in SAP FI

Document Currency

The document currency is the currency of the transaction which depends on the structure of the transaction. In our example, we’re legally obligated to pay 500 EUR. Thus our document currency is EUR. This currency is actually set on the document at the time of the transaction. When we start FB60 to book our vendor invoice, we select the document currency of EUR.

Document Currency on FB60 (1)FB60

Local Currency

The local currency is the currency of the company code which represents the legal entity in a ‘standard’ SAP configuration. This currency is used to comply with local tax reporting requirements as well as representing the functional currency as seen in FAS 52 or IAS 21.  In our example above, the functional currency for a Mexico entity is most likely MXN. That said, according to FAS 52 or IAS 21, if we suppose the primary business to be exporting ot the USA, then the functional currency might be USD. In any case, the currency is set on the company code as you can see below configuration screen.

Company Code Currency (2)Defined when you create the company code in SPRO->Enterprise Structure->Definition->Financial Accounting->Edit, Copy, etc Company Code

Group Currency

To enable reporting across all entities in an SAP environment – for doing comparative metrics and quick estimations – you can use the group currency. Since our example entity is based out of the USA, then the USD would almost certainly be the group currency. The group currency is set at the client and is consistent across all company codes. You can see the configuration below.

Currency for entire client (3)Basis can modify the client in SCC4

Tying it all together

In the configuration, you specify which currencies are relevant for which company codes. Notice that you can have up to three currencies for the company code in addition to the document currency. That allows for inflation accounting and other currency types that we haven’t covered here. In this very standard setup, we have the first currency set as the company code currency (the local currency) and the second currency set as the group currency. That means, for any transaction, we’ll have a document currency, the currency of the legal entity, and the currency of the entire enterprise.

 (4)SPRO->Financial Accounting New->Financial Accounting Global Settings New->Ledgers->Ledger->Define Currencies of Leading Ledger

Now, when we post a document, we can see that each currency type is being calculated and tracked – even if we don’t explicitly enter it!

JE with multiple currencies (5)FB60

References   [ + ]

1, 5. FB60
2. Defined when you create the company code in SPRO->Enterprise Structure->Definition->Financial Accounting->Edit, Copy, etc Company Code
3. Basis can modify the client in SCC4
4. SPRO->Financial Accounting New->Financial Accounting Global Settings New->Ledgers->Ledger->Define Currencies of Leading Ledger