ANTE User Manual

Request for Payment

A Request for Payment (RFP) is how money actually leaves the company. A maker files who needs to be paid and how much, an approver decides whether the spend is authorized, and a releaser (often the same role as the approver) picks the fund account and pays it. Every generated Purchase Order also gets its own Request for Payment automatically, so paying a PO always goes through this same approval trail.

Overview

A Request for Payment carries a payee (a supplier, an employee, or a free-text "other" payee), an amount, a payment type, an optional due date and reference number, and a memo explaining what it's for. Once filed, a request is immutable — there is no edit screen. If the details are wrong, the requester cancels the request and files a new one; this guarantees an approver never authorizes an amount they didn't actually see.

A request moves through a fixed, two-role flow:

Payment Approval → For Releasing → Payment Released

At either stage it can instead go to Rejected, and the requester can cancel it to Cancelled at any point before it is released.

One exception: a request generated automatically to pay an approved reimbursement claim skips Payment Approval — the claim's own supervisor approval already authorized the spend — and is created directly at For Releasing. See Reimbursement-Linked Requests below.

💡 This maker → approver → releaser flow is driven by a Process running behind the scenes — a Payment Request step files the request, then Payment Approval and Payment Release steps carry out the same approve/release actions as tasks, using the same actions and dialogs described below. Rejecting either step — or the requester withdrawing the request — sends the workflow back to the Payment Request step to be re-filed. By default this runs the system's built-in RFP Workflow template; an administrator can point it at a different flow under Settings → Workflows → RFP Workflow, or build one in Processes.

Getting There

Go to Treasury → Payables → Request for Payment.

The Request for Payment List

The list page header reads Request for Payment. A New Payment Request button sits at the top right (only shown if your role can file requests). Clicking it opens a payment flow picker rather than the request form directly — see File a Payment Request below.

The Request for Payment list. Each row names the payee and the amount, and the Status column shows where the request sits in the approve-then-release flow.

Stats

Four cards above the table show:

CardMeaning
Total RequestsNumber of payment requests
Total AmountCombined value of all requests
For ApprovalRequests currently awaiting a decision
ReleasedRequests that have been paid

Table Columns

ColumnDescription
RFP #The request reference (e.g. RFP-…)
PayeeWho will be paid
Payee TypeSupplier, Employee, or Other
AmountThe requested amount
MemoWhat the payment is for
StatusThe current stage (color-coded badge)
RequestedThe date the request was filed

Searching and Filtering

Search by Payee or Memo. The list is sorted newest-first by default, and can be sorted by RFP #, Payee, Payee Type, Amount, Status, or Requested date.

Click a row to open it. A request in the Payment Approval or For Releasing stage — the stages where there's something to act on — opens its request detail page directly, where you Approve/Reject or Release. Any other request (Payment Released, Rejected, Cancelled) opens its driving workflow timeline instead — a dialog listing the flow's steps (for example Submit Payment Request → Approve Payment Request → Release Payment) with status icons, plus a Task button on any step that has one to open that step's form. Requests filed before this workflow existed (with no linked flow) open the classic detail page instead.

Once at least one step's form has been submitted, an Exportable toggle appears next to Timeline at the top right of the Process Timeline section. Switching to it lists each completed step's document (Payment Request, Payment Request Approval, Payment Request Release) with an Export <Name> button that downloads a PDF copy, plus an Excel button next to it that downloads the same document as a real .xlsx workbook (through your company's active spreadsheet template for that document type, or a default layout if you haven't set one up — see Project Processes → The Spreadsheet Designer).

Each step also carries its own Download button directly on its card in the Timeline view, once that step's document is locked in — a shortcut for grabbing just that one document without switching to Exportable.

Statuses

StatusMeaning
Payment ApprovalAwaiting the approver's decision. No money has moved.
For ReleasingApproved — awaiting the releaser to pick a fund account and pay it.
Payment ReleasedPaid. The fund account has been deducted. Final.
RejectedTurned down at either the approval or release stage. Final.
CancelledCancelled by the requester (or automatically cancelled — see Purchase-Order-Linked Requests). Final.
VoidedThe request's driving workflow was cancelled while the request was still awaiting approval or release, and the cancel's void cascade nullified it. Final. A request where a payment has already moved (or is mid-release) is left standing instead — see Cancelling the Request's Workflow below.

Common Tasks

File a Payment Request (Maker)

  1. Go to Treasury → Payables → Request for Payment.
  2. Click New Payment Request. This opens the New Payment Request dialog — a Payment flow picker, not the request form itself.
  3. Leave Payment flow on Default — RFP Workflow (maker → approve → release), or pick one of your company's own custom flows from the dropdown (configured under Settings → Workflows → RFP Workflow).
  4. Click Start. The flow starts and its first step opens automatically — titled Submit Payment Request — showing the Payment Request form:
    • Choose the Payee Type: Supplier, Employee, or Other.
      • Supplier — search and select from the Payee (supplier) dropdown.
      • Employee — search and select the employee.
      • Other — type a free-text Payee Name.
    • Enter the Amount (required, greater than 0).
    • Choose the Payment Type: Bank Transfer, Check, or Cash (defaults to Bank Transfer). This describes how the payment will be made — the actual fund account is chosen later, at release.
    • (Optional) Set a Due Date and a Reference No. (e.g. an invoice or billing statement number).
    • Enter a Memo / justification (required) explaining what the payment is for.
  5. Click Submit Payment Request.

Submitting the form is what files the Request for Payment — it's created in the Payment Approval stage and no money moves yet. If the flow starts but no task could be opened for you right away, a notice tells you to pick it up from your tasks instead.

Unlike the old dialog, this form doesn't let you add a brand-new supplier inline — create it first from Suppliers, then come back and select it here.

Approve or Reject a Payment Request (Approver)

  1. Open a request that is in the Payment Approval stage.
  2. Click Approve Payment to confirm — the confirmation dialog reminds you that no money moves at this step; it only advances the request to For Releasing.
  3. To turn it down instead, click Reject Payment and enter a Rejection Reason (required), then confirm. The request moves to Rejected.

Release a Payment (Releaser)

  1. Open a request that is in the For Releasing stage.
  2. Click Release Payment. This is the only step that moves money.
  3. In the Release Payment dialog, choose the Fund Account to pay from (required) and optionally add a Memo.
  4. Click Release Payment to confirm.

The fund account is deducted, the request moves to Payment Released, and a Settlement Information section appears on the request showing the linked Fund Transaction and Source Document, plus a Download Payment Voucher button. You can also Reject Payment from this stage (e.g. wrong bank details, insufficient funds) instead of releasing.

Cancel a Request (Requester)

  1. Open one of your own requests that hasn't been released, rejected, or already cancelled.
  2. Click Cancel (top right).
  3. Confirm in the dialog — click Cancel Request to proceed, or Keep Request to back out.

The request moves to Cancelled. Cancelling is available to the requester (or a full-access account) at any time before the payment is released — since requests can't be edited, this is how you correct one: cancel it and file a new request with the right details.

If the request has a linked workflow, cancelling it also sends that workflow back to the Payment Request step — the same way a rejection does — so a fresh Submit Payment Request task appears for the maker to re-file.

Cancelling the Request's Workflow

This is different from Cancel a Request (Requester) above: instead of reopening the workflow for the maker to re-file, it ends the workflow itself — the same cancel used on Order Fulfillment, Purchasing, and Process instances.

  1. From the Request for Payment list, click a row that isn't currently at Payment Approval or For Releasing (those open the request detail page instead) to open its workflow timeline.
  2. While the workflow is still running, click Cancel at the top of the dialog.
  3. The dialog lists what cancelling will do: it will void the request if nothing is blocking it, or leave it untouched — with the reason — if a payment has already moved or is mid-release.
  4. Type a Reason (required) and confirm.

An administrator's cancel takes effect immediately; anyone else allowed to cancel only requests it, pending an administrator's approval — see Cancelling an Instance for how approval and the void warning work. Once it takes effect, every step in the workflow turns Void, the request's own Status becomes Voided (unless a payment already moved, in which case the request is left as-is), and the instance's detail page shows who cancelled it, when, and the reason.

Viewing a Request's Details

Opening a request shows:

  • An overview card with the payee, payee type, status badge, and the amount.
  • A Workflow card — the task-workflow driving this request: the instance code, the template name, a Completed or Cancelled flag once the flow has ended, and its steps (name, status icon, and assignee where one is set), with an Open task button on the currently active step. Hidden for older requests filed before this workflow existed.
  • Request Information — Payment Type, Memo, Due Date, Reference No., Project (if any), Purchase Order (if this request was auto-created from a PO), Requested By, and Requested Date.
  • Settlement Information — the linked Fund Transaction and Source Document, plus a Download Payment Voucher button, shown only after the payment has been released. The voucher PDF is generated on demand from the same GL source document the release posted, so it always matches what was actually paid.
  • Approval Timeline — every action taken on the request (created, approved, released, rejected, cancelled, or auto-cancelled), each with who did it, when, and any memo.

Purchase-Order-Linked Requests

Every Purchase Order that gets generated automatically creates its own linked Request for Payment — the payee is the PO's supplier, the amount is the PO total, and the PO number is recorded on the request. There is nothing extra to do; the request appears on this list ready for approval like any other.

When a Supplier Selection award splits across several suppliers, the Purchase Order step generates one purchase order per supplier instead of one — and each of those orders creates its own linked Request for Payment the same way, so a three-way split shows up here as three separate requests, one per PO.

Releasing a PO-linked request pays that Purchase Order directly — its balance and status move the same way (Open → Partially Paid → Paid), and the same PO can never be paid twice through it. A Purchase Order has no payment form of its own; this request is the only way it gets paid. If a Purchase Order is later paid in full some other way, its other still-open payment requests are automatically cancelled so a stale request can't be released against an already-settled order.

From either Purchase Order screen — Treasury → Payables → Purchase Order or Assets → Purchasing → Purchase Orders — opening an order that has a linked request shows a View Payment Request button that jumps straight to it, if you have access to Request for Payment. Without that access, you instead see a read-only payment-status pill so you can still tell where payment stands.

Reimbursement-Linked Requests

An approved reimbursement claim (one ANTE itself owns the books for) automatically generates its own linked Request for Payment — the payee is the employee who filed the claim, the amount is the claim total, and the memo names the claim. The claim's own supervisor approval already authorized the spend, so this request skips Payment Approval entirely and is created ready to release, straight at For Releasing.

Releasing it pays the employee back and marks the reimbursement claim as paid. Rejecting or withdrawing it also rejects the reimbursement claim, with the same reason — so the claim never sits stranded waiting on a payment request that isn't going anywhere.

Permissions

Access to Request for Payment is controlled by role, under Treasury in the permission tree:

PermissionWhat it allows
AccessView the Request for Payment list and details
Create (Maker)File new payment requests
Withdraw Own RequestWithdraw your own request (or, for a full-access account, anyone's) before it's released
Approve/RejectDecide requests in the Payment Approval stage
Release PaymentPick the fund account and release requests in the For Releasing stage — the money-moving step

For a simple two-role setup (one approver who also releases), grant both Approve/Reject and Release Payment to the same role. For stricter segregation of duties, give them to different roles so the person authorizing spend isn't the one who can also move the money.

Tips

  • Requests are immutable by design — there's no edit button. Got a detail wrong? Cancel and re-file.
  • Approving moves no money — only the release step, which requires picking a fund account, actually deducts a balance.
  • Check the Purchase Order field before approving or releasing a request — it tells you at a glance whether this request is standing on its own or paying a specific PO.
  • A rejection needs a reason — you can't reject a request without typing why.
  • Grab the voucher after release — once a request reaches Payment Released, its Settlement Information section has a Download Payment Voucher button for filing alongside the supplier's documents.
  • Purchase Order — orders that automatically generate their own Request for Payment
  • Reimbursements — approved claims that automatically generate their own linked Request for Payment
  • Suppliers — supplier records used when the payee is a supplier
  • Fund Account — the accounts a release pays from
  • RFP Workflow settings — choose which flow template drives requests filed from this page
  • Processes — build a workflow where a Payment Request step spawns Payment Approval / Payment Release steps that drive this same approve-and-release flow as tasks
← Previous
Suppliers
Next →
Aging Report (Payables)