Ameioud: Business

What Procurement Software Actually Does

2026-04-03T00:00:00Z

I've sat in enough vendor demos to know that the version of procurement software that gets shown and the version that actually gets used are not the same product.

The demo version is clean. Spend data organized by category and supplier, contracts with expiry dates visible in one place, approval workflows that follow the org chart, supplier performance scores updating from structured inputs. It's a compelling picture. The question is what the data feeding into all of that actually looks like once the implementation team leaves.

Most procurement data in most organizations isn't clean. Purchase orders exist in different formats across different systems, some of them legacy ERP instances that aren't going anywhere. Invoice data that should match PO data doesn't always match, sometimes because of tolerance clauses, sometimes because of manual workarounds that accumulated over years and got absorbed into the process without anyone ever writing them down. Supplier master data has duplicates. Fields that were populated correctly once and then never maintained. Spend categories that don't map cleanly to the cost centers finance tracks, which means every roll-up requires a reconciliation step that somebody has to do by hand.

This matters because almost everything procurement software promises to deliver depends on data quality as a prerequisite. Spend analytics needs spend data that's been categorized and cleansed. Contract management needs terms digitized and mapped to supplier relationships. Automated matching needs consistently populated fields. If those foundations aren't there, the software runs and produces output. The output just can't be trusted, and once that trust erodes it's very hard to get back.

The organizations that get the most out of these tools are usually the ones that did the data work before or alongside the implementation, not after. That work isn't glamorous. It's sitting with transaction exports, building cleansing rules, documenting what the codes actually mean, finding the edge cases that break the standard logic. It takes longer than any project timeline allocates for it.

There's also the gap between what procurement software is and what an ERP was built to do. Those two things run in parallel at most organizations and talk to each other less cleanly than anyone would like. The ERP is financial control. Procurement software is sourcing and supplier management. The integration between them is its own project, and that project has a way of becoming the constraint nobody planned for.

Working around those gaps, rather than waiting for a perfect data state that will probably never arrive, is where most of the actually useful work ends up.

Building a Business Case for Automation When Your Company Still Runs on Spreadsheets

2026-06-13T00:00:00Z

Most writing about automation assumes you are starting from an organized place. Clean processes, documented workflows, structured data. The advice is about choosing the right tool, integrating systems that already exist, or optimizing a flow that already works.

That is not where most companies are when they actually have this conversation.

When I joined a company where I ended up building most of the internal automation, the starting point looked different. Information lived in inboxes. Supplier data was spread across files that were not updated consistently and did not talk to each other. Purchase orders were created manually, logged manually, and filed in a shared drive where the naming conventions were whatever felt right to whoever uploaded them that day. When a long-term employee left, the operational knowledge they carried with them was often the only reason the process had functioned at all.

Before you can automate anything in that environment, you need to understand what is actually happening, not what the process documentation says is happening, but what the work looks like in practice. Those two things are usually not the same.

The real invoice process at that company: someone received a PDF by email, opened it, typed the relevant data into a spreadsheet by hand, saved the PDF somewhere in a shared folder, and hoped the file name was descriptive enough that someone could find it later. No naming standard. No audit trail. No way to systematically check for duplicates. That was the actual process. Understanding it clearly was the starting point for building something better.

Once you can describe what is actually happening, the business case writes itself more easily than most people expect.

The structure that works is straightforward. What does this task cost right now, in hours per week, multiplied by the cost of the person doing it? How many errors does the current process produce, and what does each one cost to fix downstream? What happens if the one person who understands the process leaves? That third question is usually the most persuasive argument in any room. Single points of operational knowledge are a continuity risk, and companies running on spreadsheets and informal processes have them in more places than they realize.

The practical trap is the circular dependency: you need to fix the data before you can automate, fixing the data requires a project, the project requires budget, the budget requires demonstrated ROI, and demonstrating ROI requires the automation you do not have yet. This loop can run indefinitely.

The way through it is to pick one process, not the most important one or the most complex one, but the one with the most consistent inputs and the most visible pain, and build something for that specific problem. Not a platform. Not a solution to every related problem. A tool for that task.

The first tool I built at that company was the PO Automator. Supplier offers were inconsistent in layout but predictable enough in content: a PDF with a set of fields that appeared in roughly the same places. The AI read the offer, extracted the data, and pre-filled a structured form. The first version was not perfect. It got better quickly because the people using it could see where it was going wrong and say so. Within a few months, PO creation went from 15 minutes to 3 minutes. That result was visible, measurable, and convincing to anyone who had been doing the work before.

The business case after that point was not a document. It was a comparison between what people remembered doing and what they were doing now.

The later challenge is the one most automation advice spends too little time on: getting tools that work individually to create something coherent. Supplier data that is consistent across the PO tool, the invoice tool, and reporting. Document naming that is systematic rather than dependent on which tool created the file. A view of operations that reflects the whole rather than several separate snapshots. That work took longer than building the tools themselves.

There is no clean version of this. You build the foundation while running the tools, not before. It is messier than the alternative. It is also the version that is actually possible.

ERP Selection Is a Political Process Disguised as a Technical One

2026-06-13T00:00:00Z

The first thing that surprised me about running an ERP implementation was how little of the actual work was about the software.

I led a full rollout at a company I worked at as the sole project manager, 11 workstreams across 6 project phases. By the time you get to go-live, you have made hundreds of decisions that had almost nothing to do with which system you selected. What processes you are standardizing. Whose workflows change and whose do not. Who has approval authority in the new system that they did not have before. Who loses the informal workarounds they had been relying on for years. Those are not technical choices. They are organizational ones that happen to require a configuration in a piece of software.

Scope creep starts before the project does.

When word gets out that an ERP is coming, every department sees an opportunity. The logistics team wants a feature. Finance wants a custom report. Manufacturing wants the system to handle a workflow that was never in the original brief. Adding things feels low-cost because the system is large and interconnected. It never is. Every addition means more configuration, more testing, more training, more places where something can break at go-live. The scope expands while the timeline does not.

The hard part is that most of these requests are reasonable. The logistics team genuinely needs that feature. Saying no to legitimate requests from people who will use the system every day creates friction that does not disappear. I said no more often than felt comfortable. Looking back, that was probably the right call more often than I gave it credit for at the time.

Translating what people need into what a system can do is harder than it sounds, and the gap between them is where most ERP projects fail quietly.

Users think in terms of what they do. Systems are configured in terms of how they work. A procurement manager who says "I need to flag a PO for re-approval if the price changes by more than 5%" is describing a workflow they built intuitively over years. Turning that into a system configuration requires understanding both what they are asking for and what the software can actually support, and those two things are often close but not identical. The gap gets bridged with a workaround. The workaround becomes the process. Three years later nobody remembers what the original requirement was, and the system has accumulated enough workarounds that the next change is harder than it should be.

Change management is not a phase of the project. It is the project.

Every piece of implementation guidance will tell you change management is important. Almost none of it is specific about what that means in practice. What it means is: getting users trained before go-live, not during. Running user acceptance testing with the people who will actually use the system, not just the technical team. Managing expectations carefully about what day one looks like versus what the system looks like after six months of use. Communicating often, even when there is nothing definitive to say.

The political dimension is this: ERP implementations redistribute visibility. Some departments get clearer reporting than they have ever had. Some lose the informal flexibility they used to work around broken processes. The people who had the most to gain from the lack of structure are often the loudest critics of the new system. Not because the system is wrong. Because it makes things visible that were not before, and visibility creates accountability.

That is not a technical problem. No configuration change resolves it.

What actually helped was keeping a live project command center with module coverage, UAT status, risk register, and issues log visible to all stakeholders throughout the project. Running UAT with real data, not synthetic test cases. Fixing issues that came up in UAT before go-live instead of logging them for later. And treating go-live as the beginning of the real project rather than the end of the implementation.

The system is never done on the day you switch it on. The distance between what was configured and what the business actually needs closes over time if you work at it. The projects that fail are the ones that treat go-live as the finish line, hand it over, and move on.