Procurement for multi-branch organizations: branch context, approvals and delivery

Why multi-branch procurement is different

Multi-branch procurement is different because every purchase has two owners: the organization that pays and the branch that receives. A single-site business can treat purchasing as one list of requests. A clinic group, a restaurant chain or a retailer with stores in several cities cannot, because the same item may be needed in different quantities, at different addresses, on different dates.

When branch context is missing from the purchasing record, familiar problems appear. Two branches order the same item separately and miss a better combined price. A supplier delivers to head office instead of the branch. Nobody can say which location is responsible for a rising spend in one category. And branch managers either have no way to request what they need, or they buy outside the system entirely.

Software fixes most of this with one decision: the branch is a field on every request, chosen from a managed list, rather than a line in the description. WOSTA, the healthcare procurement marketplace FLUIDS designed and built, works this way. Buyers manage their branches, and a new purchase request can be associated with one of them alongside its city, quantity, urgency and desired delivery date, so the location is part of the purchasing record.

How to model organizations, branches and users

The data model for multi-branch purchasing has three layers: the organization, its branches and its users. Getting the relationships right at the start avoids painful migrations later, when the first customer adds a fifth location or a regional manager.

• Organization. The legal or commercial entity that holds the account and, usually, the invoices.
• Branch. A location belonging to the organization, with a name, city, delivery address, receiving contact and, if needed, its own cost centre or reference.
• User. A person in the organization with a role (requester, approver, central buyer, administrator) and a branch scope: one branch, several branches, or all of them.
• Request. Belongs to the organization and to exactly one branch. Its delivery details default from the branch but can be adjusted for a specific order.

The branch scope is what makes permissions work. A branch manager sees and creates requests for their branch only. A regional manager sees several. The central procurement team sees everything and can buy on behalf of any branch. These rules must be enforced on the server and in the database, not only hidden in the interface, so that one branch cannot read another branch's requests or offers by changing a link.

Central, branch-led or hybrid purchasing

Before designing screens, establish how the organization actually buys. Most multi-branch organizations follow one of three models, and the software should support the one they use rather than impose another.

The hybrid model is common in practice and is where approval chains and category rules earn their place. It is also where the interface needs the most care: a branch user must understand at a glance whether a request will go straight to suppliers or wait for someone at head office.

Approval chains: when to add them and how to design them

An approval chain is a rule that a request or an acceptance needs someone else's confirmation before it moves on. It is a design option, not a requirement of every procurement product, and it should be added where the organization's own policy calls for it.

1. Choose the checkpoint. Approval can happen before a request is sent to suppliers, before an offer is accepted, or both. Approving before acceptance is often enough, because that is when money is committed.
2. Define the triggers. Common triggers are a value above a threshold the organization sets, specific categories such as equipment, or requests from branches that are new to the platform.
3. Name the approvers by role. "Regional manager for this branch" survives staff changes better than a named person.
4. Handle absence. Allow delegation or a fallback approver, so a request does not wait because one person is on leave.
5. Respect urgency. An urgent request should notify approvers immediately and show its urgency clearly, rather than joining a daily queue.
6. Record the decision. Who approved or returned the request, when, and with what comment, stored with the request history.

Keep the first version short: one checkpoint and one level is enough for most organizations. Multi-level chains are easy to draw in a workshop and hard to live with on a busy day. They can be added once real usage shows where control is actually missing.

Delivery, city and receiving at branch level

Delivery is where branch context pays off most directly. When the branch carries its city, address and receiving contact, every request inherits them, and suppliers know before quoting whether they can deliver there and when.

• City-based routing. Suppliers who do not serve a city should not receive its requests, or should see clearly that it is outside their usual coverage.
• Delivery date per branch. The same item may be urgent in one branch and routine in another. The desired delivery date belongs to the request, not the item.
• Receiving contact. The person at the branch who will receive the order, so drivers do not call head office.
• Consolidated requests. A central buyer may want one request covering several branches, with quantities and addresses per branch. This is useful but adds complexity to quotes and delivery; consider it after single-branch requests work well.
• Receipt confirmation. Letting the branch confirm what arrived is a design option that closes the loop between an accepted offer and what was actually delivered.

For organizations whose operations depend heavily on delivery and routing, our logistics industry page covers the wider set of tools FLUIDS builds around dispatch and tracking.

How clinic groups, restaurant chains and retailers differ

The branch model is the same across sectors, but what each branch buys and what can go wrong differ. Three common cases in Saudi Arabia illustrate the range:

• Clinic groups. Medical consumables and equipment with precise specifications; regulated products where suppliers and buyers carry compliance responsibility; urgency that can affect appointments. Our guide to healthcare procurement platforms covers this case in depth.
• Restaurant chains. Frequent, recurring orders for ingredients, packaging and cleaning supplies, often with short shelf lives. Delivery windows and receiving times at each branch matter more than in most sectors, and repeat ordering saves branch managers time.
• Retail chains. Store fixtures, packaging, uniforms and maintenance services alongside stock. Branch openings create one-off bursts of requests, and central teams often control branding-related categories.

Each case changes the request form, the categories and the default approval rules, but not the underlying structure of organization, branch, user and request. That is why a well-modelled procurement product can serve more than one sector, and why the sector-specific parts belong in configuration rather than in separate codebases.

Reporting by branch

Reporting by branch answers the questions head office actually asks: which locations buy what, from whom, and how quickly requests turn into accepted offers. Because every request already carries its branch, these reports come from data the workflow records anyway.

• Requests per branch and category over a chosen period.
• Open, accepted, rejected and expired requests by branch, to spot where purchases stall.
• Accepted offer values by branch and category, as a basis for budgets.
• Time from request to accepted offer, by branch and by urgency.
• Suppliers used per branch, to see where purchasing could be consolidated.

WOSTA includes reporting areas for both buyers and suppliers alongside its request, offer and invoice screens. In a new product, agree the first three or four reports with the people who will read them, and make sure the underlying records, especially the accepted offer version and its branch, are stored in a way those reports can rely on. The B2B quotation workflow explains how to keep that record trustworthy.

FLUIDS designs and builds procurement platforms, SaaS products and custom internal systems for organizations in Saudi Arabia and the GCC. See the WOSTA case study for a branch-aware procurement marketplace in practice. Scope, price and timeline are agreed in a written proposal before development.