Building Bocks of SAP - Invoice Matching and Payment
SAP unpacked by a rural based ex military super user.

Building Bocks of SAP - Invoice Matching and Payment

If you are anything like me you had a really steep learning curve when you transitioned from the military to the commercial world. I was pretty much rock climbing without a mapped route.

Basically - in the military time and people are the most precious resource. In the civilian world every decision is cost/profit driven.  I knew almost nothing about how money moved and was managed in a commercial context. Realigning my core values in that context was pretty difficult - and some of the lessons were learned the hard way.

Despite having worked in several different project management and change management roles since leaving the Army, I didn't really become an expert on Invoices and Purchase to Pay (P2P) until I took on the purchasing role at the concrete manufacturing plant.

I'll cover how to read an invoice in another article. My topic today is how to get the invoice paid in the SAP P2P environment (at least the one I worked in).

The short version is that the vendor invoice has to match the purchase order and goods receipts exactly in every critical detail before payment will be authorised. Sounds simple right?  

Except that it isn't.

In reality the entire process exemplifies the very definition of barriers to communication.

 It's a bit hard to explain if you have never seen what a purchase order looks like and aren't familiar with invoices. It's going to be easier on all of us if you just Google the words "SAP purchase order sample" and look at the images. Let me outline the sequence before I attempt to summarise where things go wrong.

  1. A purchase requisition is raised by the operator at the plant detailing all of the information required for the order. The requisition can have an unlimited number of item lines with item descriptions dictated by the database or hand typed by the operator.
  2. On completion the requisition is sent to the buyer (who is in another city) for review, cost optimisation and conversion to a Purchase Order.
  3. On creation the Purchase Order is automatically sent to the designated approving authority.
  4. The approving authority will either approve or require changes. If approved the order is sent to the supplier
  5. Crucial point to remember is that the Purchase Order can not leave the organisation until it is approved by the designated approving authority. Informal workarounds only cause you problems in the long run.
  6. Supplier receives the order, fills and delivers the goods.

 

This is where the process splits and runs in parallel and where things start to get complex. The key point to remember here is that I was operating in a system that required a three way processing match (there are other ways). That is - the purchase order, goods receipt and invoice had to match exactly. Simples!

It goes more or less like this:

  1. Supplier sends the invoice for payment to the Accounts Payable section of the business which in my case was outsourced first to India and then to the Philippines.
  2. Local operator at the receiving plant goods receipts the delivery against the purchase order in SAP.
  3. Automated process which takes care of the heavy lifting on the invoice matching process attempts to match the goods received to purchase order and the invoice received. If everything works the invoice is paid. To be fair - it's a pretty effective system. People only get involved when the invoice, purchase order and goods receipts fail to match.
  4. If any data at all mismatches or is missing - units of measure, quantities, prices, no purchase order on the invoice - the invoice is sent back to the original requisitioner via a workflow for resolution.
  5. Local operator investigates the problem and takes appropriate action to rectify.

This is where things get "interesting". In the SAP environment I worked in the only way to make changes work was to reverse the transactions back to the point of failure, make the necessary changes, then re-process the complete approval/invoice application chain. Working via third parties - via the workflow and with no option to pick up the phone and explain things in person. With no mechanism to report or rectify service problems in the incident processing flow. With overseas operators in different time zones. Frankly - tested the patience of saints - and I am no saint!

Rectifying errors gets more and more complicated and painful the further you get into the process. I didn't cause the problem but I inherited one case that was so bad it took me over twelve months to completely resolve. Someone else raised the initial purchase order on a big & complex order when I was on holidays and made a complete mess of it. I can't detail the kinds of problems it caused - that would be unprofessional.

Avoiding these messy and infuriating errors is actually pretty simple.

  1. Get to know how your suppliers invoice and compile your requisition/purchase order so that it will match the way the supplier invoices. It's really easy to see copies of invoices from previous orders. Just search for them and open them up.
  2. Good personal relationships with your suppliers will save you every time - get on the phone (their number will be in the vendor details on the order) and explain to them that the invoice absolutely has to refer to an approved purchase order number (you'd be amazed how often this gets overlooked by small & medium traders).
  3. Copy/paste successful requisitions/purchase orders for repeat orders. If it worked before it will most likely work again.
  4. Always, always, always check that the prices on your requisition are current.
  5. Attach a copy of the quote to the requisition for easy reference and accountability. Then everyone in the incident resolution chain has access to all of the relevant information.

It all comes down to paying attention to detail and getting the data right at the point of entry.

😊 Scott Macias - BSEE, MBA

Director High Tech Sales: Customer Success | Account Manager | Cyber GRC | Electronics Enthusiast | Maker

1y

Interesting!

Like
Reply

To view or add a comment, sign in

More articles by Mel O'Sullivan

Insights from the community

Others also viewed

Explore topics