During the 1990s one of our main objectives in implementing SAP R3 was to get the core SAP product installed and working. At that time many organisations had multiple different legacy systems and the benefit of a single integrated SAP ERP system was a key goal.
In terms of vendor processing in SAP the benefits included, for example, a three way match of the vendor invoice across the supply chain to the goods receipt quantity and purchase order price. While system controls improved a lot, many transactions were manually captured into SAP requiring personnel time and effort.
Vendor statement reconciliations were not catered for in SAP itself. Being at the end of the procure to pay process these were done manually, by downloading SAP reports, like vendor line items (transaction FBL1N) and GRIR (transaction MB5S), to Excel and producing vendor reconciliation reports in Excel.
Once a stable core SAP platform has been achieved, organisations start to focus on further automation. Particularly with the establishment of financial shared services centres, extensions to SAP that automate large volumes of vendor and other procure to pay transactions make a good business case.
One key area is to avoid having to capture vendor invoices into SAP. Within SAP itself, ERS (Evaluated Receipt Settlement) is long standing functionality that allows the invoice to be generated based on the purchase order price and the goods receipt quantity. ERS depends heavily on the purchase order price and goods receipt quantity being accurate (else the automatically generated invoice value is wrong). Where the vendor invoice is still preferred to be loaded into SAP to perform a three way match, multiple invoice automation tools are available from multiple vendors. For example, Open Text offers VIM (Vendor Invoice Management), while many other solutions like ReadSoft, Esker, Kofax, Dolphin – and many others – are available. Tools like Ariba and Coupa also offer invoice automation but also focus on a closer electronic link with the vendor throughout the procurement chain (as do many others including the afore-mentioned invoice automation tools). Manual capturing can be reduced and accuracy increased.
Close electronic integration with a vendor is often dependent on the vendor, of which an organisation that runs SAP can have hundreds or thousands of vendors. For example, poor quality printed or scanned invoices are difficult for systems to read. Not all vendors can integrate their own accounting systems to a tool like Ariba, and to do it takes time.
If done well, invoice and procurement chain automation go some way to reducing inaccuracies and personnel effort.
However, the issues inherent in a physical procurement and supply chain process still remain – for example:
- The vendor delivers a physical quantity (or service), but the GR (goods receipt) into the SAP system is less or more. Could be due to mistakes, broken items, fraud etc.
- There are often returns later after receipt:
- Goods or services are discovered to be damaged, expired, wrong goods etc.
- Goods or services are no longer required.
- There are all sorts of credits on pallets, bottles etc, or in the case of services on hours billed not worked or achieved.
- There are rebates, with many schemes.
- The buyer raises credit notes but these are disputed by supplier, and not entered into the vendor system, or at a different amount, or with a different reference.
- Prices on the PO (purchase order) could be wrong, either in our SAP system (in which case we want a credit), or in the vendor system (in which case if reasonable we may also allow a debit).
- Where there is a three way match block, and the vendor is informed, the vendor may dispute this, or the amount. The vendor may raise an unrelated credit note or not.
- The vendor doesn’t allocate invoices to payment timeously and thinks we owe more, or else the vendor disallows a settlement discount that was already deducted in the payment run.
- The vendor allocates payment to the wrong invoices and credit notes, and considers paid items incorrectly outstanding and unpaid items incorrectly as paid.
- Automatically processed invoices into Ariba can still require authorisation, workflows, checks (like three way match etc), before they are posted into SAP as real financial documents. These could also be reconciling differences.
A vendor statement reconciliation addresses the above physical supply chain issues:
- To see an overall picture of vendor’s system and buyer’s system together, a vendor reconciliation report is required. All the issues in the procure to pay process are reflected as unreconciled items on the vendor reconciliation report.
- Queries are reduced. While a payment remittance advice tells the vendor what was paid, a vendor reconciliation reports what is not paid and why, reducing the need for vendors to query payment. For example, if there are missing invoices, or invoices that still require approval or that have price and other discrepancies – or if a vendor invoice has been successfully processed but not paid yet according to payment terms.
On the vendor side, payments not allocated, or credits / claims not processed are also identified.
- An audit method of proving the balance sheet vendor figure is to compare it to the value of vendor statements.
Implementing SAP and other ERP solutions provides better controls over the previous manual processes, such as a three way match – and many other benefits which come with an integrated ERP system. However, the same inherent issues still exist in the physical procurement process – and a vendor reconciliation is required to identify and address these issues.
BEST is a SAP certified add-on module that automates vendor statement reconciliation directly in SAP itself. By further automating SAP to remove the manual effort and inaccuracy of producing vendor reconciliations outside of SAP, the business case is clear. Please contact us today at firstname.lastname@example.org to see a demonstration of how to reconcile vendor statements in SAP.