The adjustment to the classical invoice process by eliminating the invoice was an example of a huge leap in lateral thinking. Instead of receiving the invoice from your vendor you use the data in your internal purchasing system to produce a credit note for your vendor. The creation would be based on data from your own system and would automatically post this invoice (or better credit memo) in your integrated financial ledgers, without an AP-clerk having to do one manual entry. Al seems to be to good to be true, until there is the reality call off implementation. Bellow find some of the pitfalls :

2.1 Data in your system is not accurate
Critical element in the concept is your internal purchase order system and with it the accuracy of the data in it. You will base your credit memo on the price stated in the purchase order and the quantity stated in the goods receipt. Just imagine the goods in responsible making the famous comma-mistake and instead of entering 10,000 (ten pieces) he enters 10000 (ten thousand pieces) or the price info for your vendor material combination was updated incorrectly. In both cases you would produce a wrong credit-note and would kick off a long trial of corrections that probably take you more time to put into your system than a classical invoice would have done.
Lesson 1 : No Self-billing without a checking opportunity both internal and external before the actual creation of the credit note !

Note : For one customer the PIKON International Consulting Group has designed a function that can be executed internally as well as via a web-interface for use by the vendor. This tool almost simulates the results of a self-billing run applying some additional checking rules as well. For example a Warning light is set if the goods receipt quantity billed is more than 10 % different from the average quantity received.

2.2 National legal requirements
The fact that our one Europe is certainly not one when it comes to statutory financial requirements is not a surprise. Therefore one should also consider the international implications when embarking on a “self-billing” project. For example in France there is the requirement that a vendor has to sign or confirm the information on the credit note before it can be posted and sent. In Italy the current rules even go one step further. There the document should be similar to one created by the vendor. This means using the vendor logo or paper and using a sequential number range within an interval unique for the vendor.
Lesson 2 : Check if the national legislation has been updated to allow self-billing.

2.3 Master data maintenance
As in most integrated software packages there is the element of the master data that plays a key role in this automated process. If your data is wrong your output is wrong. On one side you should consider the vendor data. Now also things like the VAT id should be in order and printed on the document. Consider to give your vendor direct or web-based access to your system so he can maintain this for you!
Another issue that should not be underestimated is the determination of the VAT code, which applies for this transaction. Either one has to manually add it on the purchase order or info record or one should develop a procedure to determine it in the background, obviously based on master data settings in the vendor, material or process.
Lesson 3 : Review and manage the master data requirements
Lesson 4 : Decide on how to determine the tax code for the transaction

Note : At one customer we implemented a user exit that derived the tax coded based on the material tax indicator, the receiving country, the sending country and the type of plant (sub-contracting). Shouldn’t we tell the reader that solutions we made were SAP-related?

2.4 Fuzzy – purchase processes
The above-described solution can only be used when there is purchase orders and goods-receipt information that can be trusted. Especially that last element is a weakness, because this restricts the application area to the classical goods related movements, leaving out of scope the huge number of “fuzzy” purchases that do not have a clear goods receipting point or –responsible. In order to organize the “goods-receipting” of for example cleaning service or the receipt of a company car or mobile is not always so easy. To assign this responsibility to one department as you would with a goods-inward department is not so obvious. This is just one example of a case in which the self-billing approach does not work. Other examples are those where there is no purchase order at all or the process cannot be applied to the vendor for legal reasons. In those cases we come to a good second group of solutions. A group I will refer to as “workflow” and is described in the next paragraphs.

3 workflow

The alternative approach to streamlining the classical invoice receipt-process is by optimising the individual components of the process. This could include elements like scanning of documents, optical character recognition and electronic distribution & management of the document flow via workflow techniques.
 
Bellow you will find two business cases describing the application of such workflow features. The first being a low cost scenario using standard SAP R3 means and the other being a more ambitious approach to create a complete layer around the back-end system to allow flexible handling of the document stream.

3.1 Low cost scenario
In the low cost scenario we have a customer using a SAP system rel. 4.6. By using the available content repository & business-workflow functions one could realise such an infrastructure in a fairly short time span. This Infrastructure would include the scanning of your incoming documents onto a file server or optical archive. And the subsequent processing of these documents via workflow-distribution. Bellow find two scenarios of such a process. The first is a process without a purchase order in which the authorization decision is triggered by the fact that the invoice is parked. (In my opinion it is necessary to explain the process chains a bit more in detail; notes and SAP-integration (one note should point out that PIKON even realized this); we could also eyplain which benefits could be prepared by SAP-Workflow. May be that the second process must be coated because of restrictions of size) In the second scenario there are invoices based on PO’s. But in the process of posting it becomes obvious that the goods receipt has not yet been posted or is different to the invoice quantity. In this case the invoice is posted but blocked for payment. This block will now trigger an authorisation via a workflow path.

Note : In one project Pikon realised a solution with an advanced role-resolution in which the authorising user was selected via either the cost-center, the cost-account or even the vendor number. The control of this so called authorisation matrix was with a system responsible at he customer site so they could very quickly make changes to these routings.

3.1.2 Option 1 : Preliminary posting in FI
 Graph not included

3.1.3 Option 2 : Logistics inv.Verification (based on PO)
 graph not included


AdditionalDetail:

for graphs please mail john.frijns@pikon.com