Approvals and approval paths

Every purchase request goes to someone who can approve its amount. You decide who that is.

Who can approve

People with the Approver or Super user role can decide requests. Nobody can approve a request they raised, admins and super users included: if a path would send a request back to the person who raised it, it goes to super users instead.

If nobody but the requester could decide a request, its page says so and tells an admin how to fix it.

Approval paths

An approval path belongs to one person (by email) in one company in your workspace, and optionally one branch. It has:

The person’s own limit: requests up to this amount are approved straight away, with no approver.
Approvers, each with a limit: anything above the person’s limit goes to each approver in turn, in order, until one whose limit covers the total approves. That approval is final, and the purchase order follows.

For example, with Jane (up to 1,000) then Sam (up to 10,000), a request for 5,000 goes to Jane, then to Sam, whose approval is final. If no approver on the path covers the total, super users approve it last. A super user can approve at any step, and their approval is final; when it comes ahead of the path, or the total is above every limit on it, the request’s history says so, for example “Approved by Alex (super user), ahead of the approval path”. Approvers who can’t act (inactive, without the Approver role, or away) are skipped. A rejection at any step ends the request. Amounts are compared before tax, in the workspace’s home currency.

A path without a branch covers every branch of its company; a branch-specific path wins over it. Admins and super users maintain paths in Approval paths.

When an approver is away

Approvers set the days they’re away in Time away; admins can set them for anyone on Members. While someone is away, requests that reach them on an approval path go to the next approver, or to super users, so nothing waits for them. Requests already waiting for them move on when the time away starts. When it ends, requests stay with whoever has them.

An admin can also choose a colleague to cover: an active approver who can see the request’s company. Requests that reach the away approver go to them instead, they decide with the away approver’s limit, and the request’s history shows it, for example “Approved by Sam Lee on behalf of Jane Doe”. Someone covering never decides a request they raised, and nobody signs the same request off twice. Covering gives nobody a higher limit than the person they cover for.

People without an approval path

Requests from someone without a path follow the workspace’s default rule, set at the top of Approval paths:

Approve automatically up to an amount. It starts at 0, so nothing is approved automatically until an admin sets it.
Anything above goes to super users (the starting choice) or any approver.

Requests approved automatically have their POs sent straight away, so set this limit with care.

Requests in another currency

Admins can allow other currencies in Settings → Workspace → Foreign currencies, each with the exchange rate to your home currency (1 USD = 18.25 ZAR, for example). You enter the rates yourself — from your bank or accountant; Mittral doesn’t fetch them — and every change is recorded with who made it.

A requester can raise a request in any allowed currency; a supplier with a usual currency starts the request in it. The lines are priced, and the purchase order is issued, in that currency: the supplier sees only that currency, never your rate. When the request is submitted, the rate in effect is fixed on it, and its total before tax is converted to your home currency (rounded to the cent) to compare with approval limits. Approvers see both, for example “USD 1,200.00 (≈ ZAR 21,600.00 at 18.00)”.

Changing a rate later doesn’t change requests already submitted or their orders. A request recalled and submitted again takes the rate in effect then. Removing a currency stops new requests in it; drafts in it must change currency before they can be submitted. Tax is worked out with your workspace’s rate as usual; tick Zero-rated on each line that carries none, such as an import.

Importing approval paths from a spreadsheet

You can import all your paths from a CSV file with the columns Company, Branch, Submitter, Limit, then as many Approver N and Approver N Limit pairs as you need. Use email addresses for people. Importing replaces all existing paths.

Approving or rejecting a request

Approvers see their requests in Approvals, with the lines, totals, supplier, notes and attachments. They choose Approve request or Reject request; a rejection needs a reason, which the requester sees.

While a request is awaiting approval, the requester can Recall to edit it (it goes back to a draft to change and submit again) or Withdraw it. A decision is tied to the version of the request the approver saw: if the request changed in the meantime, the decision doesn’t go through and the approver reviews it again.

What happens after the final approval

Mittral creates the purchase order (PO) as a PDF from the approved request, and emails it to the supplier. Approval, the PO and its email delivery are separate steps, each with its own status, so an approved request doesn’t mean the email has gone.

If your monthly PO allowance is used up, approving still works: the PO is put on hold and the approver is told before they approve. It’s issued automatically, in approval order, when the allowance resets or the workspace upgrades. A PO on hold for 30 days needs approving again. See PO limits.

Sending, cancelling or revising a PO after it’s issued

The person who raised the request and workspace admins can change what happens to an issued PO from its request page:

Send again: email the PO to the supplier again, for example if they lost it, or to a corrected address after a typo or a bounce. It’s the PO as issued; its PDF still shows the address it was issued with. Admins can also put the new address on the supplier list. If Mittral couldn’t confirm whether an earlier email arrived, you’re asked to accept that the supplier may get it twice.
Cancel PO: give a reason (kept in your workspace, not sent to the supplier) and choose whether to email the supplier that the order is cancelled. An email that hasn’t gone yet is stopped. The request stays approved.
Revise PO: starts a draft with the same company and supplier. Change the lines or details and submit it; it’s approved like any request, on its new total, and nobody approves their own. Once approved, the next revision of the PO, with the same number, replaces the current one and is emailed to the supplier. Until then the current PO stays as it is, and a rejected or withdrawn revision changes nothing. To order from a different supplier, cancel the PO and raise a new request.

None of these counts as another PO: sending again and revisions don’t count again, and cancelling doesn’t give the PO back to your monthly allowance.