Zekal One · Approvals module

Order approval workflow for discounts, credit limits and new accounts

Every distributor runs on exceptions: a price below the floor, an account past its credit limit, a first order from a business nobody has vetted, a refund someone wants written off. Approvals turns each one into a routed decision with a name and a reason attached — and holds the order until it clears.

The problem

Right now, your approval process is a person with a phone

A rep needs a few points past the discount floor, so they text the sales manager. A reorder pushes an account past its limit, so accounting is asked to let this one through. A new customer's first order sits in a folder because nobody is sure who vets it. The order ships — or doesn't — based on who answered fastest.

Weeks later, when the margin is short or the receivable is aging, the only record of that decision is a thread on somebody's phone. The exception was probably fine. Not being able to see it, price it or repeat it is the expensive part.

Discount depthA price below the floor a rep can give on their own authority
Credit limitAn order that takes the account past its limit or its terms
New accountA first order from a customer nobody has qualified yet
Refund or write-offMoney given back after the fact, past a threshold you set

Routing

Routed by role and by amount, not by who is online

An approval request is not a message. It goes to the authority that can make the call — a role, and an amount band within it — so a small exception clears at the first level and a deep one climbs to whoever owns that risk.

  • Rules you define — discount depth, credit limit, new account, refund threshold, or whatever your business calls an exception
  • Routing by role — sales manager, controller, ops lead; the request goes to the authority, not to one person's inbox
  • Routing by amount — the same exception can clear at one level when it is small and need a second signature when it is not
  • One queue, not five threads — approvers work a list of pending decisions instead of scrolling back through chat
  • Same rules from every door — an order a buyer placed themselves in the portal is tested exactly like one a rep typed

The flow

What happens between the exception and the pick list

The exception gets caught where the order is created — not discovered later by a picker holding a box.

  • 1The rule fires at order entry — the moment a line goes below the floor or the total takes the account past its limit
  • 2The order is held — visible to everyone who touches it, and not released to the warehouse
  • 3It routes to the role and amount band that can decide it — anyone holding that authority can pick it up
  • 4The approver sees the order, not a summary — full lines, the customer's terms and what they already owe, on one screen
  • 5The decision is recorded on the order — approved, rejected or changed, with a reason and a name that stay there
  • 6Only then does it become work — a cleared order releases to picking; a rejected one never reaches the floor
Nothing picks, nothing ships

This is the part that changes behavior. When a held order is genuinely unpickable, the exception gets resolved by someone with authority instead of routed around by someone in a hurry. The hold is a state on the order, not a note taped to a monitor.

The record

The decision lives on the order, with the reason attached

A "yes" in a chat window is not a control, it is a memory. Here the decision is part of the order, so it outlives the person who made it and can be counted later.

  • Who decided, and when — on the order itself, not in a thread or a mailbox
  • The reason, in their words — "matching a competitor on this line", "this customer always pays on day 32"
  • What was approved — the order as it stood when it cleared, so a later change is visibly a later change
  • Questions you can answer — how much shipped below the floor last quarter, which accounts keep going over, who clears them

Approvals is one of the seven modules of Zekal One, which runs in production in US smoke and vape distribution on a territory of well over 100,000 accounts.

Credit hold

Credit hold as an order state, not a sticky note

Credit terms are enforced where the order is entered. An account past its limit gets neither a silent failure nor an apologetic call next morning — the order becomes a request, in front of the person allowed to release it, with the balance and terms on the same screen.

The exceptionWithout a control layerWith Approvals
Discount past the floorRep messages a manager; the order ships either wayHeld and routed by discount depth, decision on the order
Account over its credit limitSomeone in accounting is asked to let this one throughCredit hold is an order state; releasing it is a named approval
First order from a new accountSits in a pending folder nobody ownsRouted to whoever vets new accounts, with the answer recorded
Refund or write-offAgreed verbally, discovered at month endRouted by amount, reason captured with the credit

Why it matters more than it sounds

Approvals is what makes the other modules safe to open up

Most distributors want two things they are quietly afraid of: buyers ordering themselves at two in the morning with no rep in the loop, and reps closing deals without a call for every price. Both are the same bet — an exception gets caught by the system rather than by someone noticing.

Self-serve ordering is only sensible when an over-limit order routes somewhere instead of shipping. Rep discount latitude is only sensible when the exception is logged where finance can see it. That is this module's whole job: the control layer that lets you switch the others on.

Questions

What operators ask about approvals

Will it block an order to a state where the product isn't legal?

No, and we would rather say so plainly. Approvals holds no legal database of what is permitted where, and it will not stop a sale on that basis by itself. What it does is route an order to a named person when it matches conditions you define, hold it until they decide, and keep the reason. The judgment stays with your team and your counsel — what changes is that it happens before the order ships, and is written down. What the platform does do is capture the fields regulated categories require at order entry; our PACT Act reporting guide walks through that side of it.

What happens when the approver is on vacation?

Requests route to a role and an amount band rather than to one person's inbox, so anyone holding that authority can pick them up. Pending decisions sit in a visible queue, so coverage is something you can see rather than something you discover on a Friday afternoon.

Can a rep tell before submitting that an order will need approval?

Yes. Rules are evaluated at order entry, so the exception surfaces while the order is being written, not hours later when the pick list comes up short. The rep can tell the customer it is going to an approver before they hang up.

Does this work if our orders live in another system?

Approvals works on orders inside Zekal One — which is exactly why it can hold a pick list, read a live balance and write a decision onto the order. It is not a workflow tool bolted onto a foreign order table, and we claim no pre-built connector to any particular package. If your orders live elsewhere today, that is a conversation about sequencing.

Won't this slow down orders that are perfectly fine?

Only exceptions are held. Orders within terms and within pricing pass straight to the warehouse and never enter the queue. The share that trips a rule is usually small, and because every decision is recorded, you can see afterwards whether a threshold is set too tight and move it.

Show us the exception that keeps escalating

Tell us which orders stop and wait for a person today — the discounts, the credit holds, the new accounts — and we will show how Approvals routes them, and what the rest of Zekal One does once the order clears.

Book a walkthrough