AFE Approval
AFE stands for Authorization for Expenditure — a formal document the office prepares to justify a requisition that is either out of the ordinary or exceeds the available budget. It is typically sent to the site owner, signed or approved by e-mail, and returned before the requisition may continue.
The AFE belongs to the process, not to a single document: there is exactly one AFE per requisition, and its block is visible on the requisition, on the request for quotation and on the purchase order alike. Where it can be submitted and approved is narrower than where it is visible — see
The function has to be switched on in the purchasing configuration — the setting is called Use AFE (Extraordinary Expenses + Budget Overrun). Where it is off, nothing described here appears.
When an AFE is required
Either of two things triggers it:
- Extraordinary Expenses is ticked on the requisition, or
- the requisition would push its cost account over the budget limit for the current period — the pie chart under the header turns red.
An information block under the pie chart then reads AFE required (extraordinary expenses), AFE required (budget overrun), or AFE required (extraordinary expenses and budget overrun) where both apply. Once the AFE has been approved, that block turns green and reads AFE approved — on the requisition, the request for quotation and the purchase order alike.
If neither applies, no AFE is needed and the transaction runs as before.
Both triggers lead to the same procedure. They differ only in what sets them off: a tick on the requisition, or a value above the limit. Everything that follows — where the AFE has to be filled out, when it has to be submitted, and at which point approval is enforced — is identical.
If the budget graphics are switched off. Some installations hide them with the Show Budget Check option. The check still runs: when a request exceeds its budget, the AFE block with the Fill Out button appears anyway, only the pie chart stays hidden.
Several cost accounts on one request. The block then lists every assigned account with its own budget, identically on requisition, request for quotation and purchase order.
Where the requirement actually blocks
Both triggers behave identically. Whether the AFE is required because the requisition is marked as extraordinary, because it exceeds its budget, or because both apply — the route through the process is the same. Only the wording of the messages differs, so you can see which reason applies.
Neither trigger blocks the approval of the requisition, and neither stops a purchase order from being created. The requirement is enforced at the point where the order would leave the house:
The decisive check therefore happens at one single point: sending the purchase order. An order may be prepared, edited and kept while the approval is still running — but no order that requires an AFE reaches a supplier without an approved one. The check covers every dispatch route alike: e-mail, print and the sending queue.
One difference remains, and it follows from the nature of the two triggers rather than from a rule: a budget overrun can disappear when the order is edited down, while the extraordinary marking stays until someone removes it. An order marked as extraordinary therefore keeps its AFE requirement regardless of its value.
Two reasons for placing it there. At that moment the figures are real: supplier and price are known, so the AFE is decided on the actual order value rather than an estimate. And if an AFE is turned down, the damage is an internal document rather than an order the supplier has already received.
A purchase order that is later abandoned does leave traces — a number is used up and it stays in the history. That is accepted deliberately; the same already applies to an abandoned requisition.
Seeing the status in the overview
The tree of the purchase overview carries an AFE column showing the status per document as a symbol: empty (no AFE yet), to be filled out, filled out, submitted, approved, or rejected. This tells you from the list which requests still need attention, and which orders cannot be sent yet. The column only appears where the AFE function is switched on.
Opening an order that exceeds its budget also shows a notice in the AFE block stating that it cannot be sent until the AFE has been approved, next to the buttons for filling the form out and submitting it. The form is filled out from the order, not from the requisition.
When the order changes afterwards
An order that has not been sent may still be edited. The budget situation is then reassessed:
- If the overrun is gone, the marking disappears and the order can be sent normally.
- If the change causes an overrun, the marking appears and an approved AFE is required.
A form that has already been filled out or submitted is never discarded by this — only an empty task marker that was never filled out is removed again.
An approval, however, can lapse. Raising the order beyond the amount that was approved invalidates it — see
Where submitting and approving are possible
The AFE block is shown at every stage of the process, but the two actions that move it forward are tied to fixed places:
The reason is the figures: only once a supplier has been picked is the amount the real one, and an order that has already reached the supplier cannot be changed by approving it afterwards.
Everywhere else the block stays fully visible — status, the note that the order cannot be sent until the AFE is approved, and the buttons for filling out, editing and exporting. Only the button for submitting or approving is absent there. Nothing is hidden, and the export is unaffected.
Submitting requires its own permission, called AFE - Submit for Approval. It sits in the rights tree next to the other AFE permissions. Without it the submit button does not appear — neither on the request for quotation nor on the order. As with any permission change, it takes effect only after the user signs in again.
Where the approver finds the work
The approver is usually not the purchaser and does not work inside the purchasing module. Two places show the pending approvals:
The start page. The section AFE Approval Required lists every form submitted for approval, with vessel, transaction number, submission date and who submitted it. Approve opens the approval dialog directly. The section appears only for users holding the AFE approval right, and only if it is switched on in that user's dashboard configuration.
The view filter in the purchasing module. Ticking AFE to approve reduces the tree to those transactions whose form is waiting for approval. Without the AFE approval right the entry is not offered at all. The approval itself is then given on the purchase order.
There is no automatic notification — no e-mail, no alert. The approver sees the task when looking at the start page or the purchasing module. To prompt someone actively, use Send on the AFE, which prepares an e-mail draft for the owner.
When an AFE is rejected and an order already exists
Since an order may be created before the approval is settled, a rejection can now affect one that already exists. Nothing is cancelled automatically. The order stays where it is, keeps its marking, and simply cannot be sent. The purchaser decides what happens next: revise the AFE and submit it again, or reject the order.
The approver is told which orders are affected at the moment of rejection, so this is not discovered by accident later.
An approval covers the amount it was given for
Approving records which amount was decided on. If the order is later raised beyond it, the approval lapses: a message names the old and the new amount, an entry is written to the history, and sending is blocked until the AFE has been submitted and approved again. The new amount is then the approved one.
Harmless changes stay harmless. Reducing the value changes nothing, an edit that leaves the value alone — a changed remark, say — changes nothing, and rounding differences below half a percent are ignored.
What counts is the whole requisition, not the single order. One requisition can carry several orders, which is the rule with several suppliers, and the AFE covers the process as a whole. The sum of its orders is therefore compared against the approved amount, and orders already sent keep counting. Otherwise the comparison would shrink with every dispatch while the approved amount stayed put, and the difference would be free to use.
A requisition is closed as soon as a request for quotation or an order has come out of it, so no further order can be attached to it afterwards. What is left over becomes a sub-requisition with an approval of its own.
Where no comparison is made at all, deliberately:
- Orders belonging to sites with different home currencies — a sum across currencies would say nothing, so nothing is recorded and nothing is compared. Better no judgement than a wrong one.
- Orders with no currency on them are skipped.
Orders in a foreign currency are converted at the daily rate, and that rate works in both directions. If it moves against the home currency, an approval can lapse although nobody changed anything. That is not a fault — submit and approve the AFE again.
Approvals given before this behaviour existed carry no amount and are therefore deliberately left alone: they neither lapse nor block.
Four rules govern the AFE itself:
- One AFE per requisition. Filling it out again updates the existing one; no second AFE is created.
- An approved AFE is final and can no longer be edited.
- Resubmitting is possible. A submitted or rejected AFE may be filled out again, which resets the status so it passes through approval once more.
- A rejection reason is not lost. Resubmitting shows the reason the approver gave, and the attached file and remark are kept.
Filling it out
Click Fill Out next to the AFE block. A form based on the configured template opens — this is the existing expenses form, unchanged. Fill it in and save. The template is fixed at that moment: switching the configured template later affects new AFEs only, and the AFE stays assigned to its requisition either way.
If no usable form is configured, the order is blocked and the message names the cause, rather than the requirement being skipped silently. Two safeguards keep that situation from arising: the AFE cannot be made mandatory without a valid form assigned to it, and a form that is in use as the mandatory AFE form cannot be deleted — neither on its own nor by deleting the library it belongs to.
The approval dialog
Open it from the AFE block on a purchase order that has not been sent yet, or from the start page. The dialog shows:
The main button follows the status first, then your rights. As long as the AFE has not been submitted, it reads Submit for Approval — for everyone, including users who may approve. That is what the click does, and nothing more: the status becomes Submitted - waiting for approval. Only once the AFE has been submitted does it read Approve for holders of the approval right, and sign it off. After a rejection it reads Resubmit. Every step is recorded in the history.
Submitting needs the AFE - Submit for Approval permission; approving needs the approval right, as before.
The other actions:
Rejectsets the status to rejected — state the reason in the remark. A rejected AFE does not stop the requisition from being approved, but no purchase order belonging to it can be sent.Reset to Pendingputs the status back. File, remark, approver and timestamp are kept on purpose so the audit trail stays complete; removing an attached file is an administrator's job. Available only with the AFE approval right or the management override right.
Attaching the signed document
A file is required before an AFE can be approved — approving without one is refused. Accepted is the signed AFE, the owner's approval mail exported as PDF, or a screenshot of the approval.
Use Add to pick the file; its name appears in the read-only File field, and it is stored with the AFE on approval. Show opens it for checking — the file just picked if there is one, otherwise the one already stored.
Sending it to the owner
Send creates an Outlook draft: addressed to the site owner's business e-mail, with a summary of the requisition and the AFE reason, and the exported AFE attached. The draft opens so it can be reviewed and edited — ZeeBORN never sends it for you, the send button in Outlook has to be pressed.
If no owner e-mail is on file, the recipient stays empty and has to be entered by hand. Making sure every site that can trigger an AFE has an owner contact with a business e-mail avoids this.
The requisition shows whether this has happened: a red Not yet sent to Owner box beforehand, turning turquoise with the date afterwards. The marker records when the draft was created, not whether it was actually sent from Outlook.
Export saves the filled-out form to a file instead — for sending it through another channel, keeping a copy, or filing it elsewhere. Both actions are recorded in the history.
Raising the budget limit
Approving an AFE does not by itself raise a budget. Where the trigger was an overrun, the limit is still exceeded afterwards and the requisition stays blocked, with a message saying the limit has to be increased in the approval dialog.
For that case the dialog contains an Increase Budget Limit section, and the main button reads Increase & Approve, so raising the limit and signing off happen in one step. With a single cost account it shows the current limit and a field for the new one; with several, a table lists every account that is over its limit, with what is already booked, this request's share, the overrun, and an editable new limit per row.
On confirmation the limit is updated and an entry is written recording old value, new value, reason, user, time and the references to AFE and requisition. From then on the pie chart uses the new limit.
Approving without raising the limit is possible — you are warned first, and the history records that the budget was not increased.
Both triggers at once. A request can be extraordinary and over budget. The budget section is offered then as well, including after the AFE has already been approved: reopening it through Manage in the AFE block still allows raising a limit that was deliberately left alone during the approval. As everywhere, the section is only offered to users holding the AFE approval right.
When approval is blocked
Creating a purchase order from a request for quotation is refused while the AFE has not been filled out and submitted, or after it was rejected. Sending an order is refused while the AFE is missing, not submitted, still waiting for approval, or rejected.
Each message names both the reason the AFE is required — extraordinary expenses, budget overrun, or both — and the next step. Approving the requisition itself is no longer refused on AFE grounds.
Management override. Holders of that right can proceed despite a missing, pending or rejected AFE, or an exceeded budget — including sending the order. The block message still appears, followed by an extra confirmation. Every override is visible in the approval history — the right should be granted sparingly and only to roles meant to carry that responsibility.
What is recorded
Every AFE step writes an entry into the regular requisition history, with user, timestamp and document reference: filling out, submitting, exporting, sending, approving, rejecting, resetting, and each budget increase. Approving without raising the limit is recorded as such.
Each entry carries a view AFE link that opens the filled-out form directly, so an audit can move from the trail to the underlying document in one click. When an AFE is approved, a copy of the form is attached to the requisition as an internal document.
Entries cannot be deleted by users, and nothing is removed automatically. Correcting a wrong entry is an administrator's task.