Weekly Vendor Payment Run: Bills Paid Inside the Limit, Holds Explained

Sixty bills, one cutoff and a limit from treasury

A weekly payment run is a list of decisions with a deadline. Each bill due by the run date needs an approval, a match to a purchase order where the policy asks for one, and a check against everything already paid. Vendors whose bank details changed since their last payment wait until the change is verified. The total has to fit inside the limit treasury sets for the week, which in some weeks is less than what is due.

The bills, approvals and vendor bank details live in BILL. The AP policy and the PO export sit in Google Drive, the cutoff and the controller's approval slot are on Google Calendar, and treasury posts the week's limit in Slack. Under deadline, the run gets built from the approved list in BILL and trimmed by hand. That is how a re-sent invoice with a suffix on its number gets paid twice, or a payment goes to an account nobody verified.

Who works in the room

The run thread belongs to Fin, the default agent. Fin and Ada both read BILL through a lasting grant the controller approved for this room, and the room guidelines let only Fin schedule payments, after the controller approves. Ada is the second reviewer, so Fin hands the proposed list to Ada by mention before anything reaches the controller. Ryan picks up whatever leaves the building: when a bill is held, Fin mentions Ryan with the bill and the reason, and Ryan drafts the vendor notice.

One weekly run, cutoff to close

The run register is a Database App in the room, with one line per bill for the proposed action, the reason and the approver. BILL holds the bills; the register holds why each one was paid or held this week.

When the run changes before cutoff

Things move between Monday and Thursday. A late approval lands in BILL, a vendor sends a corrected invoice, or treasury lowers the limit because an expected receipt slipped. Fin re-screens only the bills each change touches, updates their lines in the register and tells the AP lead which lines moved and why. A lower limit re-runs the cut against the policy's priority order rather than dropping whatever was added last.

A bank change that arrives mid-week holds that vendor's bills on the spot, even if they were already approved for the run. The hold stays until an AP specialist's callback to the number already on file is recorded. Ryan adds a line to the vendor's notice so the vendor knows the payment is waiting on verification and not on a dispute.

What the checks catch

• Two bills from one vendor with the same amount and invoice numbers that differ only by a suffix, a dash or a leading zero
• A vendor whose bank details changed since its last payment, with no verification on record
• A run total that would exceed the limit treasury posted for the week
• A bill with no matching PO or no approval in BILL, held with the reason written on its line

What stays with people

• Approving the final payment list before Fin schedules anything in BILL
• Verifying a bank detail change by calling the vendor on a number already on file
• Setting the weekly limit and releasing funds, which belongs to treasury
• Sending each vendor notice Ryan drafts in Gmail

Integrations in this workflow

Kylon is not an accounts payable system, and BILL stays the place where bills are paid. Kylon sits across BILL, the policy files and the team's calendar and chat, and coordinates the run between them.

• BILL
• Gmail
• Google Calendar
• Google Drive
• Slack

• BILL holds the bills, approvals and vendor bank details, and is where Fin schedules the payments the controller approved
• Google Drive keeps the AP policy and the PO export the match runs against
• Google Calendar carries the cutoff, the controller's approval slot and the release time for each run
• Gmail carries hold notices to vendors as drafts the AP lead sends
• Slack is where treasury posts the weekly limit and approvers answer quick questions

Where to start

Take one weekly run. Connect BILL with a grant the controller approves for the room, create the run register App, and write one rule into the room guidelines: nothing is scheduled in BILL until the controller approves the final list in the thread, and any vendor with a changed bank account is held until verified.

“Some weeks the run is smaller. Every bill that waits has a reason someone can read.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.