eProcureAI / Platform / Replace spreadsheets and email
Use caseAlmost every customer arrives from the same place. A spreadsheet two people maintain, approvals living in email, and a month end spent working out what was actually committed.
The most common starting point. Usually live in about three weeks.
A shared tracker is a perfectly reasonable way to run purchasing for a while. It is free, everybody understands it, and for a small team it genuinely works.
What breaks it is rarely a dramatic failure. It is volume, then people. Two versions appear because somebody worked offline. The person who understood the formulas leaves. Approvals sit in an inbox during a fortnight of annual leave and nobody can say what is outstanding.
Meanwhile finance is reconstructing the picture at month end from memory and inbox archaeology, and the number they produce is the only view anybody has of what the company has actually committed.
Occasionally it is an audit finding. More often it is somebody senior asking a simple question, such as what have we committed this quarter, and discovering that answering it properly takes two days.
At that point the choice is not between a spreadsheet and software. It is between reconstructing the answer every month forever, or having it available whenever anybody asks.
Somebody edits offline, somebody else edits the shared copy, and now there are two truths with no way to tell which is current.
No queue, no visibility, and no way to say what is waiting on whom without asking people directly.
One person understands the structure. When they are away, or leave, the process degrades immediately.
The tracker records what was requested and the ledger records what was invoiced. Nothing records what has been promised in between.
Rather than a spreadsheet describing purchases, the purchase record is the thing. It updates as events happen because the events happen on it.
Rules decide who approves based on department and amount, reminders happen automatically, and delegation covers absence without work stopping.
Accruals build from open commitments and goods received but not invoiced. Both are already recorded, so there is nothing to assemble.
The honest version, including what we need from you.
| When | What happens | What we need from you |
|---|---|---|
| Week one | Thresholds agreed, charge code structure confirmed, supplier list imported | A few hours of decisions |
| Week two | Routing rules configured, catalog loaded, first requests tested | Review rather than build |
| Week three | Testing signed off, one training session per site, go live | An hour per site |
| Months one to four | Adoption grows, usually without a mandate | Nothing in particular |
| Months two to twelve | A second and often third module added | A decision about which |
The part that takes longest is usually agreeing what the approval thresholds should be, which is a conversation worth having regardless.
The fair concern. What settles it is that raising a request takes about two minutes, so the compliant route becomes the fast one.
Supplier records and open commitments are migrated. Historical transactions can be imported if you want the reporting continuity.
A specialist does the configuration with you. The typical ask is a few hours a week for three weeks.
You do not. The first module goes live and the rest of your process continues until you are ready.
Plans are modular. Start with one, add more when it is justified, without reimplementing.
Possibly not. Below roughly a hundred invoices a month with simple approvals we will say so on the call.
Nobody has to become a systems administrator, which is usually the thing that kills these projects.
Makes decisions in week one and attends one training session. That is close to the whole commitment.
Configuration, migration, testing and the hand holding through the first month.
Genuinely. It is the fastest way for us to show you what the first three weeks would look like.
Book your free demoRelated: All solutions and Intake and Approvals