When Your Excel Purchasing Workflow Needs Custom Software

A spreadsheet can be a practical place to start a purchasing process. It lets a small team record requests, organize vendor information, and share a familiar view of the work. The question is not whether Excel is “professional enough.” It is whether your current process gives people the information and controls they need.

Before considering custom procurement software, identify the handoff that is difficult to manage. A larger spreadsheet will not necessarily solve an unclear approval rule. A custom application will not solve it either unless the rule becomes part of the scope.

#Follow a real purchase through the business

Choose a recent request and trace it from its origin to the last relevant handoff. Record where the information was entered, who reviewed it, and which system held each part of the record.

Ask a location manager, purchasing coordinator, and accounting contact to describe the same request. Differences in their answers can reveal missing information or responsibilities that are not clear.

Do not start with an ideal future process. Begin with what actually happens, including exceptions. That gives you something concrete to improve and a way to explain the problem to a software partner.

#Look for coordination problems, not just spreadsheet size

Useful questions include:

• Are several people maintaining different versions of the same request?
• Can someone tell which approval is still needed without asking another team?
• Is vendor information repeated across locations or files?
• Does purchasing receive the information it needs before taking the next step?
• Can accounting identify the agreed record behind a payment handoff?
• Who resolves a request that does not follow the standard process?

These questions describe possible symptoms, not proof that you need a new system. If the problem is inconsistent naming or an unclear owner, changing the process may be the appropriate first step.

#Compare three approaches

Improve the existing spreadsheet process. Standard fields, clear ownership, and a shared approval procedure may address the immediate issue. This can be a reasonable choice when the workflow is limited and the current tools support it.

Configure an existing product. Review whether your current business software—or another available product—can support the approvals, locations, and vendor records you need. Compare the actual requirements with the available configuration, rather than assuming custom work is the only option.

Build a custom workflow. Consider this when the relevant rules, handoffs, or connections do not fit an existing tool well. Define what the new system will handle and which systems should remain in place.

The decision should follow the process and requirements. A custom procurement module does not automatically mean replacing your POS, accounting software, or every operational tool.

#What the Chizy Chiz case illustrates

Claudia Lugo of Chizy Chiz, a pizza restaurant chain in Mexico, describes custom software for vendor onboarding and categorization by location, requests, procurement, and the process through vendor payment. The described workflow connects restaurant locations, purchasing, accounting, and treasury.

In her account, Olimpo’s understanding of the process mattered alongside the software itself. She describes seeing her needs reflected in an organized workflow. You can watch the English client story and read the Chizy Chiz case.

This example supports a discussion about connected purchasing and vendor workflows. It does not establish a complete ERP, a particular accounting integration, or an outcome that another business should expect. Your approval rules and existing systems still need their own review.

#Scope one useful module first

Choose a starting point with clear boundaries. That might be request intake and approval, vendor records for a defined group of locations, or a specific handoff into purchasing. These are scoping examples, not a prescribed rollout.

For the chosen module, document:

1. Who starts the process and what information is required.
2. Which roles can review, approve, or update the record.
3. The vendor and location information needed.
4. The systems that receive or provide data.
5. Exceptions and the person responsible for handling them.
6. The scenarios you will use to review the working module.

A limited starting scope still needs enough connections to be useful. If the module ends just before the handoff that causes the most confusion, it may leave the central problem unresolved.

#Make data and responsibilities part of the plan

Identify which information should move from existing files and which records need cleanup before import. Ask who owns those decisions. A software team cannot determine the correct vendor record solely from several conflicting spreadsheets.

Also clarify permissions and the payment boundary. Organizing an approved request is different from authorizing or executing a payment. The project agreement should describe which actions the system supports and which decisions remain with your team.

Review integration access early. Name the tools involved and the information that should move between them. Where a connection is unavailable or outside the initial scope, make the remaining manual step explicit.

#Use the consultation to map the process

Bring a recent purchase example, your current files, the tools involved, and the people responsible for key handoffs. Explain which part creates the most manual coordination and what a useful first module would change.

Explore custom procurement software development with Olimpo, or map your purchasing workflow with our team. A clearer process is the starting point; the right software scope follows from it.