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.

💡 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.

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 any row to open its driving workflow timeline — 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.

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.

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. 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.

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, shown only after the payment has been released.
  • 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.

Releasing a PO-linked request pays that Purchase Order directly — its balance and status move the same way a manually recorded PO payment would (Open → Partially Paid → Paid), and the same PO can never be paid twice through it. 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.

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.
  • Purchase Order — orders that automatically generate their own 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)