The record never revisits itself

For a long time I thought the hardest problem in enterprise software was helping teams work faster inside the systems they already had. I've come around to something else. Most systems turn living decisions into dead records, and once that's happened the organization starts treating the past as though it were still the present.

It's the line I keep coming back to: the record never revisits itself. It captures what was entered at one point in time, then carries that version of reality forward long after the assumptions underneath it have changed.

A record can be accurate and still wrong

A system of record usually isn't broken in the obvious way. The data can be clean, the entry complete, the approval trail intact, and everyone involved can have done exactly the right thing with the information they had. The record can still be wrong.

It misstates nothing. What it does is keep the visible output of a decision: the chosen vendor, the signed contract, the approved budget line, the negotiated clause. What was known at the time, what was assumed, and what everyone expected to happen next don't survive the trip into the field, and those are the load-bearing parts. They're also the parts with the shortest shelf life. So the record stays accurate about the past while it gets handed back to the business as if it were the current state of things.

Why this matters more than most teams realize

Decisions in large organizations rarely fail because nobody cares. They fail because context is fragmented, timing slips, and the reasoning behind an earlier decision disappears into systems that were never built to hold it. Vendor relationships are where I see it most.

A vendor was selected because they looked like the safest option at the time. A pricing term got accepted while volumes were still uncertain, and a renewal clause was tolerated because the team had bigger operational risks to solve that quarter. Somewhere in there a category strategy was set against a market that has since moved.

Each of those was probably sound when it was made. What happens next is the problem. The record stays and the context decays, so six months later, twelve months later, or after an acquisition, someone inherits the output without inheriting the reasoning. They're not making a fresh decision at that point. They're leaning on a frozen assumption.

The real cost of stale records

A chief transformation officer at a New Zealand energy company told me about a contract she wanted out of. The vendor was underperforming, the person who'd signed the agreement had left, the contract wasn't in their management system, and the email had been deleted. They ended up asking the vendor to go and find the original correspondence, which took three months. By then the termination window had closed and they were locked in for another twelve months with a vendor they'd already replaced.

It's tempting to file that under edge case. I've heard versions of it in most large organizations I've spent time in.

Contracts sit in old inboxes, spend sits across systems that don't talk to each other, and two teams negotiate with the same supplier without either knowing the other exists. Renewal dates pass before anyone works out that they mattered. M&A makes all of it worse, because the vendor list doubles overnight and a good deal of the institutional knowledge leaves with the people who held it.

None of that is a people problem. It's structural.

We built software around process, not understanding

The old model of enterprise software wasn't foolish. It solved a real problem: organizations needed systems that imposed order, reduced cognitive load, and made work repeatable, which is what ERPs, finance platforms, contract repositories and workflow tools were built to do. They're good at turning messy activity into structure, and much weaker at helping an organization re-interpret that structure once the world moves.

A program follows rules defined in advance, and it works best when the future behaves the way somebody expected it to. Commercial environments don't sit still. Suppliers change behavior, markets move, internal ownership shifts, and risk accumulates in places you can't see from inside any single system. What the business needs is context that stays alive, rather than a static trail of transactions and documents.

This is the conviction behind Cotiss

Cotiss exists because we came to believe that the most valuable commercial information in an organization is the reasoning around the record, which is the part nothing in the stack was built to keep.

Why this vendor was chosen, why the clause mattered when it was written, why a renewal exposure is still sitting there, why spend keeps moving outside contracted terms, why two teams are buying from the same supplier under different assumptions. Most companies can't answer any of that quickly, even when the information exists somewhere, because it's spread across email, the ERP, finance tools, contract repositories, SharePoint and people's heads. There are pieces of the truth everywhere and almost never a connected view of the whole.

What we're building connects and structures that fragmented vendor data, so a business can see where spend sits, where risk sits, and where savings are still available before costs get locked in and the leverage is gone.

From a single source, usually email, we can surface about 95% of an organization's total vendor spend, and on average we identify at least 1% in savings across non-headcount opex and capex. At real scale, that's material money. It's also why our first use cases are so practical: off-contract spend, CPI increases, missing rebate terms, service credits, renewal exposure, duplicate supplier arrangements. Those are decisions a company can act on now.

From stale snapshots to living commercial memory

The shortest description of Cotiss is a CRM for vendors instead of customers, giving an organization a connected view of the relationships, obligations, spend, performance and history that sit on the cost side of the business. Even that description is too small for what I think this category becomes.

The part that holds my attention is commercial memory: a system that keeps more than the last known state and helps the business understand what that state means now. A record tells you a contract exists. It takes something else to know that the renewal window is close, the vendor has been slow to respond, spend has drifted outside the agreed terms, and the assumptions behind the original deal don't hold anymore. That's the move from keeping records to reasoning from them.

Why I believe this shift happens now

For years this was too hard to attempt. The data was too fragmented and too dependent on human memory, and you could only get reliable value out of a system when the inputs were already structured and clean.

That constraint has gone. We can connect and structure messy commercial information now, infer the relationships running through unstructured data, and work with what an organization actually has instead of the tidy version it wishes it had. It changes the starting point, because a large business no longer has to wait for a perfect migration, a workflow overhaul or a multi-year transformation program in order to become visible to itself. The information already exists. The work is making it usable.

A personal note on how we got here

Cotiss didn't start where it is now. We began as a source-to-contract platform and it worked, it delivered value, and procurement teams used it well. Over time I became convinced that we were treating symptoms downstream while the real problem sat upstream. Teams were being asked to make commercial decisions without a complete picture of their vendor network, so the savings were real and the visibility was partial, and the software helped people run the process without touching the fragmented context underneath it.

I stopped asking how to make another workflow better and started asking why organizations make high-value vendor decisions with such incomplete memory in the first place. Everything we've built since comes out of that question.

What this means from here

I think the next generation of enterprise software gets defined by contextual understanding far more than by process enforcement. The systems that matter will be the ones that help an organization see more clearly, reason more continuously, and act before the moment passes, which is a different design goal from storing the most records.

That's what we're building at Cotiss: a living layer of Commercial Intelligence that helps an organization revisit what matters before the cost of not knowing is already locked in. I'm still working out how far that goes. If any of this sounds like your own operation, I'd like to compare notes.