Source-to-Pay+ is Extensive (P25) … And Contract Management Very Extensive … So Here Are 80 Contract Management Companies to Check Out!

And now the post you’ve all been waiting for! A partial, starting, list of 80 contract management companies that may (or may not) meet some, or many, of the core baseline capabilities we outlined in the last three parts of this series (Part 22, Part 23, and Part 24) as we discussed the Negotiation, Analysis, and Governance sides of Contract Management today. (For those of you who skipped these posts, please note that we define a Contract Analysis solution as one which supports the syntactic, semantic and numeric [spend] analysis of the contracts and that we do NOT include a vendor that focusses [just] on numeric [spend] analysis of the contracts.)

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), and Supplier Management Companies (in Part 20), we must again give our disclaimer 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 any document management companies (that could store contracts) in our expository on how Contract Management can be a NAG.

Furthermore, as we’ve said before, not all vendors are equal, and we’d venture to say NONE of the following are equal. The companies below are of all sizes (very small to very large, relative to vendor sizes in our space), cover the baseline differently (in terms of percentage of features offered, the various degrees of depth in the feature implementations, and differing levels of customization for a vertical), offer different additional features, have different types of service offerings (backed up by different expertise), focus on different company sizes, and focus on different technology ecosystems (such as plugging into other platforms/ecosystems, serving as the core platform for certain functions or data, offering a plug-and-play module for a larger ecosystem, focussing on the dominant technology ecosystem(s) in one or more verticals), etc.

Do your research, and reach out to an expert for help if you need it in compiling a starting short list of relevant, comparable, vendors for your organization and its specific needs. For many of these vendors, good starting points might be found in 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, a second reminder that inclusion on this list DOES NOT imply Sourcing Innovation is recommending the vendor.

Company LinkedIn
Employees		 HQ (State)
Country		 Negotiation Analytics Governance
Aavenir 69 Plano, Texas N G
Advanced 2680 United Kingdom G
Agiloft 259 California, USA A G
AnyData Solutions 10 United Kingdom A G
Atamis 40 United Kingdom G
Aufait 114 India G
Bonfire 87 Ontario, Canada G
BrightLeaf 65 Massachusetts, USA A
Brooklyn Solutions 23 United Kingdom G
Cloudia 40 Finland G
Cobblestone Software 131 New Jersey, USA A G
Concord 71 California, USA N G
Conga 1571 Colorado, USA N G
Contract Hound 37 New York, USA G
ContractLogix 32 Massachusetts, USA N G
ContractPodAI 294 United Kingdom N A G
Contract Safe 18 California, USA G
Contracts Wise 2 United Kingdom G
Contracts 365 19 Massachusetts, USA G
Corcentric 588 New Jersey, USA G
Coupa 3674 California, USA N G
datanet 2 Colorado, USA G
Deep Stream 25 United Kingdom G
Delta eSourcing ?? United Kingdom G
DocuSign 7538 San Francisco, USA N A G
ebidToPay ?? Bavaria G
eBrevia (DFIN) 23 New York, USA A
Elcom 18 United Kingdom G
ElectrifAI 132 New Jersey, USA A
Eyvo 24 California, USA G
Evisort 234 California, USA N A G
FullStep 128 Spain G
GateKeeper 103 Illinois, USA G
GEP 4650 New Jersey, USA N G
iCertis 2263 Washington, USA N A G
Ignite Procurement 60 Sweden G
Inconto 9 Netherlands G
Intenda 111 South Africa G
Ion Wave 22 Missouri, USA G
ISPnext 59 Netherlands G
Ivalua 849 Ivalua N G
Jaggaer 1266 North Carolina, USA N A G
Juro 125 United Kingdom N G
Kira Systems 48 Ontario, Canada A
Legal Robot ?? California, United States A
Legal Sifter 31 Pennsylvania, USA A
LGX Corporation ?? North Carolina, USA G
Litera 1104 Illinois, USA A
Malbek 89 New Jersey, United States N G
Market Dojo (Esker) 34 United Kingdom G
MarketPlanet 72 Poland G
Medius 562 Sweden G
Merlin Sourcing 29 Germany G
Oalia 22 France G
Onventis 129 Germany G
OpenGov 603 California, USA N G
ParleyPro 16 California, USA N G
Outlaw 7 New York, USA G
Penny Software 35 Saudi Arabia G
Proactis 557 United Kingdom G
ProcurePort 8 Indianapolis, USA G
ProcureWare (Bentley Systems) 4830 Pennsylvania, USA G
Prokuria 8 Romania G
Raindrop 27 Raindrop G
Ready Contracts 243 Australia G
SafeSourcing 10 Arizona, USA G
SAP (Ariba) 2963 California, USA G
ScanMarket Symfact (Unit4) 60 Denmark G
ScoutRFP 44 California, USA G
SirionLabs 918 California, USA N A G
Sourcing Force 4 Ontario, Canada G
Sourcing Insights 9 Indiana, USA G
SupplyOn 239 Germany N G
Synertrade 180 Germany G
Trade Interchange 27 United Kingdom G
Trakiti 12 United Kingdom N G
Unimarket 77 New Zealand G
Vortal 188 Portugal G
Zycus 1464 New Jersey, USA A G

Come back for Part 26 as we continue our discussion of Source-to-Pay.

The Procurement People-Process-Technology Pain Cycle …

Recently on LinkedIn, someone asked the trick question of which came first: process or technology. The answer, of course, was people since, when Procurement, the world’s second oldest profession, started, it was just a buyer haggling with the seller for their wares. and this is how it was for a long (long) time (and in some societies was as far as “procurement” progressed), until shortly after a culture advanced to the point where people could form private businesses that were entities unto themselves. Once these entities started to grow, and multiple people were needed to do the same job, they realized they needed rules of operation to function, and these became the foundations for processes.

But when business buying began, there was typically no technology beyond the chair the employee sat in, the table they used to support the paper they wrote their processes and records on (and the drawers they stored the paper in), the quill and ink they used to write with, and the container that held the ink. And in many civilizations, it was like this for hundreds of (and sometimes over a thousand) years. The first real technological revolution that affected the back office was the telephone (invented in 1876, the first exchange came online in 1878, and it took almost 30 years for the number of telephones to top 1,000,000 (600K after 24 years, 2.2 million after 29 years). [And it took 59 years before the first transatlantic call took place.] The next invention to have a real impact on the back office was the modern fax machine and the ability to send accurate document copies over the telephone. Even though the history of the fax machine dates back to a 1843 patent, the modern fax machine, that used LDX [Long Distance Xerography], was invented in 1964, with the first commercial product that could transmit a letter sized document appearing on the market in 1966. Usage and availability was limited at first (as the receiver need to have a fax machine compatible with the sender), but with the 1980 ITU G3 Facsimile standard, fax quickly became as common as the telephone. But neither of these inventions are what we consider modern technology.

When we talk about “technology” in modern procurement, or modern business in general, we are usually talking about software or software-enabled technology. This, for some businesses, only became common place about 30 years ago (since most businesses could only afford PCs, and even though they were invented in the 1970s, it was the 80s before they were generally available commercially, and the 90s before most smaller businesses could afford them [for the average employee]), and only commonplace in the largest of businesses 50 years ago. Once has to also remember that the first general purpose automatic digital computer built by IBM (in conjunction with Harvard) only appeared in 1944, and that IBMs first fully electronic data processing system didn’t appear until 1952, and, as a result, back office technology really only began in the fifties, and was only affordable by the largest of corporations. (Furthermore, even though he first MRPs were developed in the 1950s, the first general commercial MRP release wasn’t until 1964, and it took over a decade until the number of installations topped 1,000. [And MRP came before ERP.]) In other words, technology, beyond the telephone [and fax] did not really exist in the business back office until the MRP. And it wasn’t common until the introduction, and adoption, of the spreadsheet. The first spreadsheet was VisiCalc, on the Apple II, on 1979. This was followed by SuperCalc and Microsoft’s Multiplan on the CP/M platform in 1982 and then by Lotus 1-2-3 in 1983, which really brought spreadsheets to the masses (and then Excel was introduced in 1985 for the Mac and 1987 for Windows 2X). (And 36 years later Excel is still every buyer’s favourite application. Think about this the next time you proclaim the rapid advance in modern technology for the back office.)

In other words, we know the order in which people, process, and technology came into play in Procurement, and the order in which we need to address, and solve, any problems to be effective. However, what we may not fully realize, and definitely don’t want to admit, is the degree to which this cycle causes us pain as it loops back in on itself like the Ouroboros that we referenced in our recent piece on how reporting is not analysis — and neither are spreadsheets, databases, OLAP solutions, or “Business Intelligence” solutions as every piece of technology we introduce to implement a process that is supposed to help us as people introduces a new set of problems for us to solve.

Let’s take the viscous cycle created by incomplete, or inappropriate, applications for analysis, which we summarized as follows:

Tool Issue Resolution Loss of Function
Spreadsheet Data limit; lack of controls/auditability Database No dependency maintenance; no hope of building responsive models
Database performance on transactional data (even with expert optimization) OLAP Database Data changes are offline only & tedious, what-if analysis is non-viable
OLAP Database Interfaces, like SQL, are inadequate BI Application Schema freezes to support existing dashboards; database read only
BI Application Read only data and limited interface functionality Spreadsheets Loss of friendly user interfaces and data controls/auditability

This necessitated a repeat of the PPT cycle to solve the pain introduced by the tool:

Technology Pain People Process
Spreadsheet Data Limitations Figure out how to break the problem down, do multiple analysis, and summarize them Define the process to do this within the limitations of existing technology
Database Performance Issues Define a lesser analysis that will be “sufficient” and then figure out a sequence of steps that can be performed efficiently in the technology Codify each of those steps that the database was supposed to do
OLAP Stale Data Define a minimal set of updates that will satisfy the current analysis Create a process to do those updates and then re-run the exact same analysis that led to the identification of stale data
BI Tool inability to change underlying rollups / packaged views define a minimal set of additional rollups / views to address the current insight needs, as mandated by the C-suite create a process to take the system offline, encode them, put the system back online, and then do the necessary analysis

In other words, while every piece of technology you implement should solve a set of problems you currently have, it will fail to address others, introduce more, and sometimes bring to light problems you never knew you had. Although technology was supposed to end the pain cycle, the reality is that all it has ever done is set it anew.

So does that mean we should abandon technology? Not in the least. We wouldn’t survive in the modern business world anymore without it. What it means is that a technology offering is only a solution if it

  1. solves one or more of the most significant problems we are having now
  2. without introducing problems that are as significant as the problems we are solving

In other words, technology should be approached like optimization (which, in our world is typically strategic sourcing decision optimization or network optimization). Just like each potential solution returned by a proper mathematical optimization engine should provide a result better than the previous, each successive technology implementation or upgrade should improve the overall business scenario by both solving the worst problems and minimizing the overall severity of the problems not yet addressed by technology.

This is why it’s really important to understand what your most significant business problems are, and what processes would best solve them, before looking for a technology solution as that will help you narrow in on the right type of solution and then the right capabilities to look for when trying to select the best particular implementation of that type of technology for you.

Use IT or Lose IT!

No-bid quick buy, another overspend
You know Finance wasn’t involved again
I said hey, you, what you gonna do …
when audit comes for you?

Use it or lose it
Sweet pain is the name of the game
I said hey, hey, hey

You better use it, before you lose it
You better use it, don’t throw it away, hey
You better use it, before you lose it
You better use it, don’t throw it away, hey
Hey, hey, hey, don’t throw it away, hey

e-Sourcing, e-Procurement tools
Now online SaaSApps, subscription pools
I said hey, you, what you gonna do …
when audit comes for you?

Use it or lose it
Process is on your side
I said hey (hey), hey, hey, hey

You better use it, before you lose it
You better use it, don’t throw it away, hey
You better use it, before you lose it
You better use it, don’t throw it away, hey
Hey, hey, hey, don’t throw it away, hey

Sweet pain is the name of the game
I said hey, hey, hey

You better use it, before you lose it
You better use it, don’t throw it away, hey
You better use it, before you lose it
You better use it, don’t throw it away, hey
Hey, hey, hey, don’t throw it away, hey

Don’t throw it away.

Stop Sanctifying Savings, Recognizing ROIs without Research, or Seeking Solutions Solely in Software

If you’ve been reading the doctor for any length of time, you’re probably a bit confused about the third part of this title — as the doctor is one of the biggest proponents of sustainable software solutions that cover the extended Source-to-Pay process and enable next generation Sourcing and Procurement. However, just because he believes you should have an appropriate software solution for every stage of the source-to-pay process, that does not mean he believes all of the solutions are in software alone. Some are in systems, which are composed of talent, technology, and transformation(al processes).

Sometimes the solution to a challenge isn’t (just) a better system, it’s a better process. Take invoice overpayments, common in large organizations due to over-billings, duplicate billings, and even fraudulent billings. The current “solution” is to use a recovery firm who will take 1/3 of what they “recover” for you as their fee, but they won’t recover everything (since anything off contract is hopeless, as is any fraud that slipped through — the perpetuators are long gone, and even if the authorities find them, by the time you get a judgement in court, they’ve spent, laundered, or transferred the money to somewhere you can’t touch it). This is not much of a solution, because if only 50% of the overspend is addressable, and you lose 1/3 of that in fees, you’re only recovering 1/3 of your overspend. Ouch!

The solution here is better process enabled by technology. When an invoice comes in, the system auto-processes it and auto-matches it a purchase order and a goods receipt. If there is no PO, and it’s not a pre-defined monthly billing, it’s marked as no-pay until manually verified by the buyer that a) the invoice is for goods that were ordered and b) all of the units / services are the agreed upon prices or rates. And even then it’s held for payment until the goods are marked as received or the services delivered. If there is a PO, it must match all of the yet unmatched units (if multiple shipments, and thus invoices, are made against the PO) and each unit must be billed at the approved (contracted rate). If not, it’s flipped back to the supplier for correction. If the supplier won’t correct, possibly because the order was expedited at managerial insistence and the supplier agreed only if a premium could be charged, then it needs managerial approval before a payment can be issued, and if that is not given, it needs to enter a dispute process. In other words, no invoice is paid until matched, verified correct, and, when necessary, granted managerial approval — and the entire invoice management function is governed by a well thought out, defined, and detailed process (with flow-charts that govern process flows) that ensures every invoice is processed correctly in every situation (based upon whether or not the goods and/or services are under contract, PO, cyclic billing agreement, ordered from a catalog, requisitioned at a defined rate scale, bought in an e-auction, etc. In other words, the process comes first, and the technology enables it.

This means that while the software should enable as much of the process as possible, you shouldn’t look to the software, or even the vendor, to define the process for you. The vendor should have best practices, and should provide you with sufficient configuration options to make it work for the process you need, but you need to understand what you need before you select a solution. Some solutions on the market will be really rigid, and others will expect you to configure it to your needs. In other words, software can provide you with what you need to complete the solution, but software alone is not a complete solution — you need the right process and the right people using it. So don’t look to a software provider as the solution, look to a provider to provide software that will provide the software part of the solution.

And, more importantly, don’t accept the promised ROI without doing your own research. Most providers will promise you an ROI of 5X to 15X in an effort to convince you that NOT buying their solution wold be the stupidest thing ever as every day you’re not using their solution you’re flushing money down the toilet. And if the ROI of a solution is that high, you should definitely have a solution — but the solution that gives you that ROI might not be the one that promises it. Remember, ROI is realized return / total solution cost, and depending on how good you were doing before buying the solution, the current market conditions, your industry, and the ancillary costs of the solution (implementation, integration, training, etc.), the ROI for your organization could be drastically different than their average ROI for their average customer. For example, while the vendor’s average customer might see an ROI of 5, you might only see an ROI of 2.5, and at a multiple of less than 3, it’s likely not the solution for your organization. (Unless it’s the only solution and you need a software solution, but it’s rare that there’s only one software solution that would work.)

If you’re given an ROI, ask for the calculation the vendor uses and how you would calculate it for your own organization and do it yourself. Add padding into the price, and when you have an expected range of savings and/or cost avoidance, err on the side of caution (the lower end). That’s the number you use when considering the value, not the vendor’s number. Every situation is different, and you need to understand how different your situation is from their average customer.

However, the most important thing to understand is that you need to stop sanctifying savings and believing that the savings numbers provided by a vendor are a result of their solution. Or that you will achieve anything similar. Remember, “savings”, which is usually just “unnecessary cost avoidance”, is a function of how much the organization is spending across its addressable categories, how much overspend is across those categories, and how much was able to be captured — and this is dependent on organizational size (annual revenue), industry, and spend profile. If your organizational spend is considerably smaller, your addressable spend is less than industry average (long term locked-in contracts, etc.), or your overspend in high volume / dollar categories is less than industry average (either because you had good negotiators, or you cut the contracts at the most opportune time), then your expected “savings” will be considerably less than their average customer savings they are presenting to you. In other words, like ROI, the advertised number may not be what you get. Specifically, your savings might not be anywhere close to their advertised number.

But that’s not the most important reason you need to stop sanctifying savings — the most important reason you need to stop sanctifying savings is that there is absolutely no correlation between the savings numbers and their software. Let’s repeat that. There is absolutely no correlation between the savings numbers and their software. Why? The same reason you should not seek solutions solely in software.

The reality is that, depending on the situation at hand, sometimes most of the “savings” or “cost avoidance” results from a better process alone and has nothing to do with the software solution whatsoever. Also, sometimes the solution that is needed is simply a workflow that enforces a process, a RFX solution that collects comparable information, an e-procurement solution that supports contracted rate catalogs and rate cards, etc. These standard solutions are offered by dozens of vendors and if the majority of the “savings” or “cost avoidance” comes from a baseline solution, it literally doesn’t matter what vendor’s solution you use! Literally. So if the vendor with the significant savings number is asking 1M annually in license fees and a smaller vendor offers a solution with all the necessary baseline functionality for 120K annually, you could get the same savings for 1/8th of the cost (which would significantly impact the ROI).

In other words, when you are given a savings number, you have to do your research and figure out

  • what percentage of those savings results solely from the fact that the implemented solution enforces a proper process
  • what percentage of those savings results solely from the baseline functionality that is available in at least 3 to 5 other solutions (at a lower annual license cost)
  • … and what percentage of those savings result from advanced features found only in that solution

For example, if only 5% of the savings results from advanced functionality and your estimated annual savings from addressable spend for the first 3 years is only 10M per year, are you really willing to spend 8X as much in license fees for an incremental savings of 500K? The answer here should be a resounding NO as that incremental savings is less than the incremental solution cost! But if you’re a multibillion dollar corporate, that could save 50M a year for three years, with a 10% incremental savings from the advanced functionality, then you would be saving an extra 5M per year at an incremental cost of 800K (which is a 6X ROI) AND have advanced functionality that could be applied to all categories that might squeeze out an extra percent here and there.

In other words, what solution you should buy depends on which solution you expect will give YOU the greatest ROI based upon YOUR calculation, not the vendor’s customer averages (or outrageous quotes from multinationals who spend 10X what you do). Furthermore, don’t misread the title — you do need software to enable your Sourcing, Procurement, and Supply Chain, but the software is not the total solution — which requires the right process driven by the right people. So don’t expect the vendor to solve all your problems, just the software portion (which you should only buy after identifying what you need, and the vendor you should choose should be that which has the greatest expected ROI for your organization, as calculated by you).

Source-to-Pay+ is Extensive (P24) … Time for More Contract “Management”, but it’s a NAG. Let’s end with Governance!

In Part 21 we noted that after Supplier Management came Contract Management because the only way to lock in the opportunity was to get a contract signed on the bottom line. However, like Supplier Management, Contract Management isn’t consistent across vendors because each has a different idea on what Contract Management actually is … and sometimes isn’t. (And most vendors are jumping on the AI bandwagon faster than fleas on the only stray dog in town, but that’s a rant for another day, or week — there’s so much absurdity here.)

However, as noted in our last two posts, Part 22 and Part 23, most of the definitions, and the implemented capabilities, tend to fall into three categories: Negotiation, Analytics, and Governance. Two days ago we started by breaking down negotiation and yesterday we tackled analytics, so that just leaves governance. So today we’ll tackle governance.

Before we continue, we should point out that what we are calling contract governance includes the baseline functionality that many people used to call contract management in the early days, but since

  • the capabilities of contract systems have multiplied and varied significantly since the early days, resulting in the definition of management being too jumbled and nebulous to be useful and
  • management is more than just an electronic filing cabinet, especially when an organization really needs is control of, and by, the contract (which is an archaic definition of governance, by the way)

what we are really talking about here is not nebulous “management” but true contract governance, and a foundation for relational governance as part of an organization’s GRC (Governance, Risk, and Compliance) strategy (but that’s beyond this series).

Finally, please remember that this is not meant to be an exhaustive list of capabilities you may find, or need, but a starting list of capabilities that should be present in any tool you are considering.

BASIC

indexing and classification w/ full doc management capability
At its foundations, a governance solution must support full document management functionality with deep indexing and classification support for contracts. And that indexing must be customizable to the organization for fast location of contracts by customizable hierarchical indexes, key metadata, filters, and easy searches.

obligation, deliverable, and expiration tracking and management
The entire point of contract governance is ensuring the contract is executed because, while you may want a SaaS solution configuration to be “set and forget”, that’s the last thing you want a contract to be! While you want to trust your supplier, you also want to verify that the obligations are being met, on time and to spec, the billings are done for agreed upon rates, to the payment terms, and any issues are appropriately addressed and adequately resolved within the specified timeframes.

This means that obligations, deliverables, and expirations need to be tracked, their current state maintained at all time, and issues need to be easily surfaced and reported on.

alerting & notifications
In addition to constant monitoring, the platform must also support the definition of custom alerts and notifications, with email/instant messaging support and escalations through channels and notification chains if issues (such as deliverables being late, disputes going unresolved, etc.) are not resolved within a timely fashion.

amendment and addendum management
Few contracts, especially in the project / services category, survive their lifespan without needing at least one amendment (or addendum) as a result of a needed change order, so it’s critical that the solution support amendment and addendum management as well.

equal support for buy-side and sell-side
We really shouldn’t have to say it, but a contract governance system should govern ALL contracts, both buy and sell side. You have obligations, deliverables, terms and conditions on both types of contracts and need to manage, monitor, and report on them both on a regular basis.

ADVANCED

dispute resolution
The goal of a good contract negotiation is to end up with a contract that both parties are comfortable with, agree to, and are willing to execute to the dotted i’s and crossed t’s. However, despite the best of intentions, sometimes misunderstandings will arise, and these could lead to disputes. [And sometimes the best of intentions were not in the hearts of all people on one, or both, side(s), and issues are going to arise, and some of these issues are going to turn into disputes.] Disputes need to be resolved, and the process needs to be managed, the communications tracked, and the resolutions and agreements archived in an effort to prevent the disputes from recurring.

asset management
Contracts are for goods or services. Contracts for goods are for goods for use or goods for resale. Goods for use fall into two categories, consumables, which should be managed as inventory, and durables, which are used for execution of the business (like furniture, machinery, electronics, etc.). These durables are typically assets and should be tracked and managed in conjunction with the contracts that governed their acquisition (and their warranty and associated services, etc.). And while there are separate asset management systems, and the organization may prefer to acquire and use one, you still want the link between assets and contracts because, chances are, the asset management system will generally not maintain that link.

project management
Services contracts are generally for the implementation and delivery of projects with multiple phases, deliverables, and obligations, which need to be managed … like a project. While the organization can choose from a multitude of traditional project management solutions to manage the project, the project should not be managed independent of the contract, so a good contract governance solution should contain at least standard project management capabilities.

budget support
The entire point of a contract is to manage spend, and, hopefully, stick to the budget. So while your e-Procurement solution should support, and monitor spend against, the budget, it’s also very, very, useful if the CLM solution can, on a regular basis, import spend and monitor spend against active contracts and show performance against budget for all contracts in a category, for a supplier, etc. so that an organization can see if the contracts are keeping the projects and categories on budget, or not.

event monitoring (re obligations, deliverables & clause triggers)
While you likely have solutions that monitor external events that might impact your suppliers, or your organization in certain geographies (natural disasters, political events, new regulations, modified tax/tariff/custom rates, etc.), how many of these monitor events and identify those that might impact specific contracts? Likely none. That’s why a good governance solution will import this event data from these solutions and associate it with contracts, and then use the alerting and notification capability of the platform to let you know when a contract (obligation and deliverable) might be at risk.

Next up: The Vendor List in Part 25!