So, What Should We Do With Contract Analytics?

Now that we have looked into the power of Contract Analytics as well as the features that we need to make it truly deliver upon the promise of intelligent document processing, what can we do with it?  We should probably start with the most critical pain points for General Counsel, Procurement and business unit leaders:

• Contract Discovery: In my experience, the first step of any contract analytics project is simply finding all of the contracts located on local drives, shared drives, SharePoint sites and even email servers (because so many just get left as an attachment to an email);
• Contract Classification: After finding all of the contracts – which even for some of the best-organized organizations can take days – the next step is to figure out which ones are actually active and how the mass of agreements, addenda, appendices, purchase orders and more all fit together;
• Standardized Language: The next step is to start working through the contract language, which should be easy when that language comes from your own standardized contracts, assuming of course that those contracts are standardized, which they so often aren’t and instead have inconsistent naming, inconsistent or even no meta-data tagging, not to mention a lack of harmonized clause libraries or playbooks;
• Making sense of third-party paper: Of course, making sense of standard terms doesn’t work when you don’t have standard terms, which is in a nutshell the dilemma of third-party paper – and why, by the way, the experts say that value leakage on a third-party contract can be from 5% to 15% of the contract’s value; and
• Analytics: All of the above are pain points, but they can also be considered as the investments necessary to produce the returns on the analytics that they make possible . . . if that analysis actually happens, to determine such things as portfolio risk analysis, cost of capital, geo-political risks, and currency exchange fluctuations – which all too often it doesn’t (which means that fixing the above are just wasted investments).

So, how do we keep the investments that come from solving these pain points from being wasted?  Contracts analytics in the abstract seems like a great idea, but such programs are far more likely to be successful if they have specific goals in mind.  And that brings us to several potential use cases, all with clear goals.  Our first two operationally-focused use cases are ones that most if not every organization of any size will face.  We will then discuss two more compliance-focused ones that, while less common now, are increasingly critical for the companies that face these issues.

1. Evergreen contracts are agreements between parties that are automatically renewed after a certain date or each completion, until canceled by the deliberate action of one party or another. Many evergreen contracts have very specific requirements for cancellation, often with 30, 60 or even 90 day limits before the date of the automatic renewal by which a party must cancel.  According to Gartner Group 60% of all supplier contracts automatically renew without the knowledge of the buyer simply because the buyer fails to give notice of termination, which means that there are an awful lot of evergreen contracts out there that must be more like “zombie contracts,” still moving inexorably forward even after they should have died years ago.

For such evergreen contracts, the goal of any organization should be to extract the start date, renewal date, notice period and any other requirements for cancellation and then connect those dates the necessary system of record (even if it is just somebody’s Outlook calendar!) to give the organization a fair chance to analysis whether it wants to renew before it is forced to have to review.  And for those “zombie contracts” it’s critical to hunt them down, figure out whether there is any further value to be gained, assess the ongoing risks and make certain that they are terminated “with prejudice” when the earliest opportunity arises.

2. Procure to pay issues present the need to detect performance obligation clauses to make certain that the organization is not missing out on opportunities. While it is difficult to put a hard number or percentage on it, many procurement agreements offer volume, prompt delivery, prompt payment or other discounts.  But – at least until the “smart contracts” take over – contracts can’t enforce themselves.

The goal here is to prevent inaccurate vendor billing or inefficient internal reporting that can cause overpayment under the clear terms of the agreements.  After all, if nobody in your organization knows about these terms, that means nobody is going to act upon them.  And relying upon “the kindness of strangers,” as in hoping that your counterparties will always tell you when you should be paying them less, doesn’t seem like a particularly good strategy.  This means that you need to extract terms like volume discounts, payment conditions and deadlines, expiration, delivery, price, and quantity, volume discounts as well as ongoing or periodic rebates.  You also need to match purchase order and invoice information on those date, delivery, price and quantity terms against the contract terms, and connect that information as seamlessly as possible to your ERP, CLM or other system or database that can keep track of where you stand against those volume discounts or the like.

3. The EU General Data Protection Regulation (GDPR) is rapidly becoming one of the most serious compliance issues for organizations to deal with not just within the EU, but across the entire globe. Experts report that the world’s 500 biggest corporations are on track to spend a total of $7.8 billion to comply with GDPR.  At the same time, according to the recent International Association of Privacy Professionals and EY Annual Governance Report 2018, more than half of all companies are far from compliance and nearly one in five may never comply.

As I mentioned in an earlier blog post, companies that believe that they will somehow be immune to GDPR issues, will find that the new Regulation has a far broader, extra-territorial reach than the Data Protection Directive that it replaced.  Any companies in the US or elsewhere that do business with EU “data subjects,” not just EU citizens, are required to adhere to the provisions of GDPR.  As well, the GDPR, along with rulings of various courts in the EU, have greatly expanded the definition and scope of the “personal data” of these data subjects that must be protected.  Thus, the goal for GDPR compliance is clear: companies must review all existing agreements that could involve data “processing” – and extremely broad term under the GDPR - third party processors, identify possible gaps and take appropriate remediation steps to ensure compliance.

For some agreements, those processing terms are clearly spelled out, such in the spate of new “Data Processing Agreements or Addendums” – sometimes known as “DPAs”[1] issued by many of the major international data controllers like Amazon, Microsoft and Oracle.  Some of those agreements are clearly comprehensive and compliant with the GDPR requirements, but others , well, not so much.  Even some of the agreements that I have seen from some of the biggest controllers have terms that are at best vague and in some cases clearly improper under the GDPR (no, I am not going to name names, sorry).  This means that companies need to extract the terms from those agreements/addenda and compare them on exacting terms against the GDPR requirements, to prevent potential nasty surprises later.

For many smaller organizations (and, let’s face it, pretty much every organization is smaller than those), the agreements are quite often far more vague, with scattered terms across a large master services agreement or even several related agreements (remember that “Classification” pain I mentioned above?).  Because of the complexity of the GDPR requirements, such that the terms of GDPR Article 28(3) alone set out dozens of specific boxes that must be precisely checked, that requires careful detection of the key terms and careful analysis against the requirements – all in a format that makes sense of what would otherwise be an overwhelming amount of information.

4. Finally, Accounting Standards Codification ASC 606 is a new revenue recognition standard that affects all businesses that enter into contracts with customers to transfer goods or services. ASC 606 prescribes a new methodology for recognizing revenue from ongoing relationships with customers, how to identify the obligations, determine the transaction price and allocate the transaction value to performance obligations.  According to Deloitte, “the new standards significantly increase the amount of information companies are required to disclose about their revenue activities.”  The rule became effective at the beginning of 2018, though effectively the impact will be felt for many companies when they need to report some form of transactional event.

Companies need to extract all information in their contracts relating to performance obligations, the transaction price associated with goods and services and the amount that may be recognized as consideration for goods and services delivered.  Failure to do so will put the organization out of compliance with Generally Accepted Accounting Principles (GAAP), an utterly untenable situation for any company because so many compliance obligations are driven by GAAP requirements.

[1] Even though these agreements are sometimes called “DPA”s by some who work with such contracts, I actually would recommend being exceedingly careful in using that term in connection with these agreements because “DPA” is also the commonly-used short-hand term used by Privacy professionals to refer to the Data Protection Authorities, the EU regulators such as the UK’s ICO, France’s CNIL and Italy’s the Garante, that enforce the GDPR.