Why I’m Building a Procurement Savings Tracker
I entered procurement with no industry background and found a reporting problem hiding between negotiated savings and Finance-approved value.
A few hours before I bought procsave.com, I had no idea what procurement savings tracking meant.
I understood the obvious version. A company spends money. Procurement negotiates a lower price. The difference is the saving.
The real version became confusing almost immediately.
Two people inside the same company can look at the same supplier negotiation and report two different savings numbers. Procurement can call a project successful while Finance refuses to approve the value. Both can have reasonable calculations.
That disagreement is why I’m building ProcSave, a procurement savings tracker for teams that need to prove what happened after a negotiation.
I entered procurement from the outside
I found this market while researching software categories with expensive problems and weak tooling. Procurement savings tracking stood out because the work affects millions in company spend, yet a surprising amount of the reporting still happens in spreadsheets, slide decks and email threads.
I had to learn the language before I could understand the problem. Identified savings are different from negotiated savings. Negotiated savings are different from implemented savings. Implemented savings are different from realized savings. Finance can apply another definition before the number reaches an executive report.
The number changes as the project moves through the company.
A buyer can negotiate a 10% unit-price reduction and still deliver less value than the original calculation. Purchase volume can fall. The business can change the specification. Currency can move. A supplier can add a fee elsewhere. The new price can be agreed in a contract but never reach the invoices being paid.
The spreadsheet is expected to preserve the entire history while several teams edit different versions of it.
Payment terms showed me how messy one number can become
Payment terms gave me the clearest example of the problem.
Suppose a company moves $2 million of annual supplier spend from Net 30 to Net 60. The company keeps its cash for an additional 30 days. The working-capital release is roughly $164,384.
That sounds like a $164,384 saving until Finance asks where the expense changed.
The company still pays the same invoices. The $164,384 is a one-time cash release on the balance sheet. If Finance applies an 8% cost of capital, the recurring annual economic value is about $13,151. Neither number is automatically the same as a reduction in the procurement budget.
The calculation is simple. The classification decides whether anybody trusts it.
I built a free payment terms savings calculator to make that distinction visible. It shows the cash release separately from annual economic value and lets teams compare an extension with an early-payment discount.
Building it forced me to think about what the full product needs to record. A result without its assumptions is hard to defend. The spend amount, old terms, new terms, effective date, funding rate and Finance approval all belong next to the number.
The spreadsheet is carrying too much responsibility
Spreadsheets are good calculation tools. The problem begins when one file also becomes the project database, approval workflow, audit trail, executive dashboard and source of truth.
Every company appears to have its own savings taxonomy. Some count cost avoidance. Others keep it separate. Some report working-capital improvements beside profit and loss savings. Others exclude them from the headline number. The definitions live in methodology documents, but the day-to-day evidence lives somewhere else.
That separation creates predictable arguments.
Procurement reports the negotiated value. Finance asks whether the saving reached an invoice. The business owner questions the baseline. Leadership sees a total without knowing which parts are forecast, realized or approved.
By the time everyone agrees, the reporting period has moved on.
The software should keep the calculation, evidence and approval state together. A person reading the number six months later should be able to see where it came from without finding the employee who built the original spreadsheet.
I’m validating the workflow before building the full product
My first instinct with software is to build quickly. This time I started with the parts that help me learn.
I sent messages to procurement leaders and asked how their teams prove that forecast savings became realized, Finance-approved value. I created an early-access onboarding flow that asks one question at a time about team size, current tools, reporting problems and approval processes. I also built free calculators, a tracker template and a written savings methodology.
Each resource tests a different part of the product.
The calculator tests whether people need help classifying value. The template shows which fields they expect to track. The methodology reveals where definitions create confusion. The onboarding data helps identify which teams feel the problem strongly enough to change their process.
This takes longer than opening a code editor and inventing a dashboard, but it gives the product a better chance of matching how procurement teams actually work.
What ProcSave needs to become
The product should give procurement one place to track a savings initiative from forecast to Finance approval.
Each project needs a baseline, calculation method, owner, timing, evidence and approval history. Forecast value must remain separate from realized value. Working capital must remain separate from profit and loss impact. Dashboards should show leadership which numbers are approved and which still depend on assumptions.
The hard part will not be drawing the dashboard. The hard part will be making the underlying number credible enough that procurement, Finance and the business owner accept the same version.
I am still new to this industry. That creates extra work because I cannot rely on years of procurement experience to fill the gaps. It also means I have no attachment to the current process.
I can keep asking why a team needs five spreadsheets to explain one saving.
ProcSave will work if it turns that explanation into evidence everyone can review. Until then, I have more procurement people to speak with and more assumptions to test.