In our last post, Part 31, we noted that, after covering e-Procurement, Spend Analysis, Supplier Management, Contract Management, and e-Sourcing, it was finally time to complete our coverage of core Source-to-Pay with Invoice-to-Pay (I2P), the last core module required for a Source-to-Pay solution. Even though your e-Procurement solution will accept invoices and support some basic processing, because we noted that the ability to accept and store invoices was a core requirement for e-Procurement back in Part 5, most platforms don’t support efficient processing (and that’s why most organizations only fully review 15% to 20% of invoices). Even if the buyers are smart and use the basic features to focus in on the invoices with the largest discrepancies between the billed amount and PO, or the largest dollar volumes, even minor over-billings on the unreviewed 80% can add up.
Moreover, there’s more value to be had than just preventing overspend before it happens and allowing a small team to do the work that couldn’t be done by a team five times the size before modern technology. That’s the value that a modern invoice to pay solution must offer, and that it will offer if, at a minimum, it supports the core capabilities outlined in this installment.
As with all of our previous discussions of technology, we will separate the requirements into basics (that no invoice-to-pay solution should be without) and advanced requirements (where at least some should be present if you are selecting an appropriate solution for your organizational needs).
BASIC
360-invoice capture
An invoice-to-pay / accounts payable solution must capture all invoices submitted through all channels, not just those submitted through the platform (as PO-flips). A buyer should not have to upload, manually create basic metadata, or request an invoice to be uploaded and indexed. Whether the invoice comes in as a PO-Flip, an XML/EDI submission through an integration, a PDF sent through email, a file uploaded, etc., the platform should automatically capture it, extract the key meta-data, associate it with the appropriate purchase order if there is one, detect if it is (likely) duplicate, and notify the buyer it has been received. Baseline OCR capability, natively or through an integration, is also assumed.
recurring invoice support
When we say every invoice, we mean every invoice — not just purchases for goods and services that go through the e-procurement system, but also monthly rentals (for assets and storage), local utilities (which don’t have a PO, but arrive in the same format each month for the same service with just different usages, rates, and totals), standing supporting services (negotiated before the systems were implemented), and so on. These systems must support these invoices, have placeholder virtual purchase orders to tie them to (for tracking purposes), and ensure they are paid appropriately.
approvals & workflows
Depending on what the invoice is for, how much it is, and whether or not it matches the PO, it might be the case that it can be automatically approved with an appropriate rule, approved by the processing clerk, approved by the AP manager, approved by the AP manager after being approved by the lead stakeholder, or may require C-Suite approval. The application must be capable of supporting arbitrary sequential and/or parallel approval chains that can adapted over time as the business situation changes.
supplier portal
The application must contain an easy-to-use supplier portal where the supplier can log in, up-load/PO-flip an invoice, get current insight into the invoice status, send and receive messages, manage a basic profile, and let the buyer know when their payment details change.
fulfillment/tracking (ASN)
The application must support capturing of fulfillment status and should support ASNs and other standard e-Documents, which a supplier should be able to communicate through the API or an appropriate e-Document format sent to a dedicated e-mail address. A buyer should know when the order was acknowledged, the expected shipping date, and when the order actually shipped with associated shipping information.
goods receipts/asset management
The application must support goods receipts (that can be created by the warehouse staff) and allow goods to be marked as assets, consumables, and goods-for-resale. The application should support basic asset management/tracking, especially if the organization does not have a specialized asset management system.
intelligent m-way match on full and partial invoices
The system must be capable of not only matching an invoice to a purchase order, but also to a goods receipt, contract, and even an existing invoice if it looks like a duplicate or an updated version. It must detect when an invoice is for partial PO fulfillment, associate it properly, and when an invoice could be matched against multiple unfinished POs, choose the most likely one based upon volumes (and, if the buyer is able to determine otherwise, allow the buyer to reassign as appropriate).
OK-to-Pay / payment system integration
The whole point of invoice-to-pay is to approve a payment, and then ensure that payment gets made, so while an invoice-to-pay system doesn’t need to support integrated payment capability, it does need to feed AP systems, preferably through a direct integration, but, depending on the payment system, the best it may be able to do is file-based integration through the creation of a daily pay / update file, which is then picked up by the other system on a daily basis.
ADVANCED
dispute resolution
Not all invoices submitted are going to be correct, or acceptable to the organization for one or more reasons. Disputes are inevitably going to arise, and a good Invoice-to-Pay / Account Payables platform will contain a built-in dispute resolution mechanism that will track all disputes, all communications related to the dispute, and all agreed upon resolutions.
credit-notes
Sometimes the result of a dispute, an audit, a quality issue, or a missing shipment will be a credit note. The system must be capable of tracking those notes and associating them to the appropriate invoice, or, if that invoice is already paid, the next most appropriate invoice, as well as tracking what the credit note was for, the original associated invoices, and the dispute, if any, the credit note correlated to. And it has to make sure that the payment information sent to the payment system is modified to take the credit note into account (and provide any appropriate information in the notes).
post-audit compliance
In many countries, (e-)invoices are subject to post-audit and reviewed by tax authorities after being issued. Why? They want to ensure they get any taxes and duties due to them. This model, which is mainly used by the EU and some Commonwealth countries, requires that e-invoices be preserved and made available for audit for a minimum time (which is often 7 to 10 years). But it’s much more than saving the invoice in an e-folder — the “authenticity and data integrity” must be insured by way of digital signatures, EDI, and/or other appropriate business controls.
clearance compliance
In many other countries, especially in Latin America and Asia Pacific (although they are now popping up in some European countries as well), clearance models are becoming the norm for e-invoicing. With these models are extensive regulations and specifications on when and how invoices (and sometimes subsequent payments) are to be exchanged (as well as preserved). The entire model is geared toward the elimination of tax evasion, and in some countries not only must the invoices meet a plethora of requirements, but must even be transmitted to the supplier through a government authority that will keep a copy of the invoice.
tax compliance (tariffs, etc.)
A good invoice-to-pay/accounts payable system will either contain detailed tax rate information, or integrate with a tax compliance system with detailed tax rate information, and use that to verify the taxes being charged on each invoice are correct. It will also track any tax exemptions the company has obtained and make sure those taxes are not charged, as well as track any tax it has to pay, but (may be able to) reclaim at a later time.
dynamic discounting
A good invoice-to-pay/accounts payable solution will support dynamic discounting and allow the buyer on a suppiler-by-supplier basis, and invoice-by-invoice basis, give the supplier an option to receive early payment in exchange for a slight invoice discount. This could be the same for every supplier, or different, and it can be one offer for, say, payment in 10 days, or multiple offers for payment in 5, 15, or 30 days (on 45 day terms).
supply chain financing support
A good invoice-to-pay/accounts payable solution will also support one or more supply chain financing options, such as invoice factoring, by supporting one or more third party services that offer supply chain financing for suppliers who need / want financing where the buyer cannot offer, or is not interested in offering, dynamic discounting or other early payment models.
deep coding support
A good invoice solution will not only accept invoices from any channel, and in any format; not only support customized, and customizeable, invoice formats from each supplier to allow for automatic data extraction and codification; but also allow those formats to evolve over time as needed so that, over time, the percentages of invoices that can be automatically processed, coded, and matched approaches 100% (and, hopefully, reaches 98%+). Basically, all data should be capable of being captured natively in the I2P solution in the internal format, and, as time progresses automatically extracted.
adaptive OCR/outsourcing correction support
Building upon the last requirement, we need to recognize that, even today, some invoices will still be (partially) handwritten (when the emergency plumber shows up to stop the flooding, the locksmith changes the locks on short-notice, etc.). As such, the platform should support (adaptive) OCR as well as integration with one or more codification services that will correct and complete the extractions for all invoices where core information could not be identified or the confidence is less than 90% for the extracted data.
fraud detection
Finally, especially for post-audit countries, the solution should contain some fraud detection capability, and at least be capable of ensuring the invoice is from a known supplier (through SIM/ERP integration), for products/services the organization has ordered (in the past), correspond to a PO if the category of the products/services requires a PO, not be for anything that was already paid, is for agreed upon (if they exist) or market rates, and is being requested to a verified account. While it’s almost impossible to catch and prevent all fraud (especially collusion where one party is internal), it should prevent the obvious or easily detectable attempts.
Again, this is not a complete list of what an invoice to pay module might have to offer, or necessarily should have, as systems should constantly continue to improve, but should represent a baseline of what the module must have to be considered a modern solution.
Come back for Part 33, which will be the final installment in our initial foray into Source-to-Pay, for a potential list of vendors with which you may begin your search.
