You’ve worked your way through the S2P series and are working your way through finding the initial solution(s) that you need and putting together a plan to select, implement, integrate, train on, and utilize those solutions as part of your daily processes. Since you’ve selected a number of best-of-breed modules (because you realized that you don’t necessarily need a suite, that no suite is best in class across all of the modules, and many of the modules only need endpoint connectivity because you’re not jumping back and forth when you’re within the process of that module), you’ve started wondering about the best way to integrate them (beyond data-based endpoint integration), and, more importantly, how to manage the projects around them (especially since it’s very likely that you won’t find general purpose S2P project management in any of the modules, as even suites can be lacking in this regard).

[Even if you selected a suite, you should still read on to find out just what that suite should be doing to make sure you are getting maximum value, especially since, and we’re sorry to tell you this, the 6 basic modules that form the core process are just the beginning — you will still need data enrichment, ESG/CSR, integration with services management, asset management, inventory management, logistics and supply chain, and other features these core modules won’t have in order to get to the next level of enterprise buying once you get through the first two rounds of opportunities.]

That really depends on

• what S2P project tracking/management capability you have in the modules you bought (i.e. if the spend analysis module came with a savings tracking module that allowed you to define and track all sourcing/procurement projects at a high level, that may be enough, or it may not)
• how much insight / visibility stakeholders need into the process status (some modules may provide them with the free/read-only access they need, some may not)
• how much of your work comes from (one-off) requests vs. corporate purchasing mandates (i.e. are you mainly purchasing bulk products for resale, bills of material for engineering, etc. or are you purchasing a lot of start-up kits for new-hires, one-off requests for conferences/events, special BoMs for build-to-order, etc.)

If i) the spend analysis module contains basic project management in it’s saving tracking component ii) the stakeholders only need visibility during the selection and award phase of e-Sourcing, and they have that through the e-Sourcing module and iii) the team does very little one-off purchasing as they are supporting a manufacturing operation that has low turnover and only goes to the same old shows every year, then chances are customized end-point integration between the modules will be enough.

But, if i) the only “project” tracking is in the e-Sourcing tool and it ends at the award identification, ii) the stakeholders need visibility into the award process, contract negotiation cycle, and current/outstanding POs, and iii) there is a lot of one-off purchasing that needs to not only be tracked, but the status regularly communicated, then you may need a solution to integrate them in a process-oriented workflow and provide visibility into where each purchase request and project is to the appropriate stakeholders. These solutions are typically known as “intake” (and often marketed as intake-to-procure or intake-to-pay) or “orchestration” (and typically marketed as “procurement orchestration” or “sourcing orchestration”) solutions and are starting to pop-up rather regularly now.

The first solution, the granddaddy, of these was Per Angusta, which was recently acquired by SpendHQ. Founded in 2012 to manage the source-to-pay workflow, Per Angusta built one of the first open API frameworks to allow it to integrate with best-of-breed solutions on the market across the Source-to-Pay cycle, and to allow those best-of-breed companies to easily integrate with it proactively. By the time of its acquisition, it integrated with over two dozen best-of-breed solutions (and even a couple of suites) that allowed organizations to incrementally build their source-to-pay workflow in the order that made sense to them, and then easily integrate all of those solutions through one integration to Per Angusta.

It was more-or-less by itself for the first half of its existence, but since then options have cropped up to help you orchestrate the process, some within existing vendors (to provide an interface to the organization and orchestrate their various modules) and some new solutions to solve the orchestration process (and some of these vendors are now building core procurement/payment capabilities if they started as “intake” solutions).

So what are these solutions? And what do they do? We’ll tackle the latter question in our next installment [Part 35] (and then provide a list of vendors in the installment after that).

As promised, here is a partial, starting, list of over seventy-five (75) Invoice-to-Pay/Accounts Payable companies that have many of the baseline features we outlined in our last installment (Part 32) of this series. Please note that this list is in no way complete (as no analyst is aware of every company), is only valid as of the date of posting (as companies sometimes go out of business and acquisitions happen all of the time in our space), and does NOT include companies that may have baseline invoicing but are primarily e-Procurement companies and don’t have more than the absolute invoicing basics (and virtually none of the additional features of a modern e-Invoicing solution as outlined in our last installment). While many might consider those e-Invoicing/Invoice-to-Pay/Accounts Payable vendors, they are not under our definitions.

As with our lists of e-Procurement Companies (in Part 7), Spend Analysis Companies (in Part 12), Sacred Cow Companies that do, or support, customized “spend” analysis on Marketing, Legal, and SaaS (in Part 13), Supplier Management Companies (in Part 20), Contract Management Companies (in Part 25), and e-Sourcing Companies (in Part 30), we provide the company name, URL and LinkedIn URL if available, headquarters country, and other offerings we are aware of.

Do your research, and reach out to an expert for help if you need it in compiling a starting list of relevant, comparable, vendors for your organization and your needs. For many of these vendors, good starting points are the Sourcing Innovation archives, Spend Matters Pro and Gartner Cool Vendor write-ups if any of these sources has a write-up on the vendor.

Finally, note that when we say Source-to-Pay, it means that vendor offers modules that also cover Sourcing, Supplier/Vendor Management, Contract Management, Spend Analytics, and e-Procurement. As to whether or not SI would consider these modules meeting the majority of baseline functional requirements, you will have to check the previously published starting vendor lists in those areas.

Shout-Out to the The Revolutionary for identifying some I2PAP companies the doctor would otherwise have missed.

We ain’t done yet. Come back for Part 34 where we begin to tackle the next set of emerging applications to manage the Source-to-Pay process!

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.