Batch Vendor Payment Runs in Muin

A Payment Run pays several approved vendor bills together in one operation. Instead of opening each bill and clicking Pay, you queue up the bills, confirm a single funding decision, and release the payments as a batch. Every run is tracked — who started it, which bills were included, when it went out, and how it completed.

Payment Runs are meant for the weekly or biweekly AP cycle that most finance teams already follow. If you pay twenty vendors every Friday, this is the screen that makes that possible in a few minutes.

When to Use a Payment Run

Approved Bills → Payment Run Wizard → Pay Now or Schedule → Confirm → History

Use a Payment Run when	Use Pay-on-Bill when
You have multiple approved bills to pay in the same cycle	A single urgent bill needs to go out immediately
You want a single audit record of the batch	The bill is unusual and you want it tracked on its own
You want safety checks (vendor concentration, early-pay savings) before paying	You have already confirmed payment details manually

Starting a Run

Navigate to Finance > Payment Runs. You can either:

Click New Payment Run on the Payment Runs page
Select approved bills on the Bills page and use the “Pay Selected” action, which jumps directly into the wizard with those bills pre-selected

Only bills in Approved status can be added. Pending, rejected, scheduled, or already-paid bills are not eligible.

The 4-Step Wizard

The wizard walks you through four steps. A progress bar at the top shows where you are, and the Back/Next buttons let you move freely between steps — your selections persist as you navigate.

Step 1 — Select Bills

A table lists every bill in Approved status. For each bill you see:

Vendor name and bill reference
Amount
Due date
Early-pay badge (when applicable — see below)

Check the bills you want to include in the run. The summary row at the top shows how many of the available approved bills are selected. You can also use Select All / Clear to toggle every row at once.

Early-pay detection. If a bill has an early-pay discount configured and the wizard’s effective payment date falls on or before the early-pay deadline, the Early Pay column shows the savings amount. If the deadline has already passed, the column shows “deadline passed” instead. This is a deterministic calculation on the bill’s own discount configuration — no AI, no surprises.

Step 2 — Funding Source

The funding source step confirms where the money will come from. In the current release Muin uses each vendor’s default payment method (ACH, check, or card on file). A tip panel on this step explains the behavior so you are not surprised by per-vendor routing differences.

Future releases will add a bank-account picker powered by Plaid; for now, keeping vendor defaults is the supported path.

Step 3 — Schedule

Choose when the batch runs:

Pay Now — payments release as soon as you confirm the run
Schedule for Date — pick a date in the future; the run holds as a draft until the scheduled day

Scheduling is useful for matching payment timing to your cash-flow cycle. It also affects the early-pay calculation — bills whose discount deadline falls on or before the scheduled date still qualify for savings; bills that would miss the deadline drop out of the savings total on Step 4.

Step 4 — Confirm

The Confirm step is your last safety review before money moves. It shows:

Panel	What It Displays
Summary	Bill count, total amount, vendor count, and when the run will release
Unresolved bills warning	Appears if any selected bill was deleted or archived between Step 1 and Step 4
Spend concentration alert	Warns if a single vendor accounts for more than half the run
Early-pay savings	Total discount amount captured across all qualifying bills, with the effective date called out
Per-vendor breakdown	Each vendor and their share of the run, sorted by amount

Confirming from this step releases the payments (or queues them for the scheduled date) and takes you to the run’s detail page.

Spend Concentration Alert

The Confirm step shows a warning when a single vendor makes up more than 50% of the run’s total and the run contains at least two bills. The alert names the vendor and the percentage, so you can decide whether to split the vendor into a separate run, defer some of their bills, or proceed knowing the run is weighted.

This is a deterministic calculation on the bills you selected — not a statistical model. The threshold is a safety rail to prevent accidentally paying one vendor everything in a mixed batch, not a judgment on your vendor relationships.

Early-Pay Savings

When a bill has an early-pay discount (e.g. “2% off if paid within 10 days”), the wizard tracks the savings automatically.

Step 1 shows a per-row badge for each bill whose early-pay deadline has not passed relative to the wizard’s effective date
Step 4 sums the qualifying savings into a total savings panel, called out in the success color and tied to the effective date

If you change the schedule on Step 3 — for example, moving from Pay Now to a date a week out — the savings automatically recompute. Bills whose deadlines fall before the new scheduled date drop out of the total.

Draft Persistence

The wizard saves its state every time you navigate between steps. If you close the tab, walk away, or get interrupted, you can come back to Payment Runs and pick up where you left off.

On return, if a saved draft is found, the wizard shows a dialog with two choices:

Resume — loads your draft state (selected bills, schedule, notes) and drops you on the step you left off on
Start Fresh — discards the draft and starts a new run

Drafts are per-user — other finance teammates never see your in-progress work. Only one draft per user at a time; starting fresh replaces the saved draft.

If draft saving fails for any reason, the wizard shows a warning toast rather than silently losing your work. You can continue the wizard, but you will not be able to recover state after a reload.

Idempotency

Every wizard instance generates a single idempotency key the moment it opens. When you click Confirm, the key goes to the server with the request. If you click Confirm twice — or the network retries after a flaky connection — the server recognizes the repeat key and returns the original result instead of creating a second payment run.

This matters most for Step 4. If you are unsure whether your first click went through, it is safe to click again. Muin will not charge twice.

Success Confirmation

When a run completes cleanly — every bill was paid — the wizard fires a short celebration: an animated toast with a checkmark, canvas confetti, and a direct link to the run’s detail page. The celebration respects prefers-reduced-motion; if the user has reduced-motion preferences enabled at the OS level, the toast and confetti still appear but without the animation.

If the run completed partially — some bills succeeded, some failed — the wizard shows a neutral success toast with the success/failure counts instead. Failures are then visible on the detail page, where you can retry the failed bills individually.

Run Detail Page

After confirming, you land on the Payment Run detail page. It shows:

AI summary — a short plain-language narrative of the run (who ran it, totals, vendor mix, success/failure counts). Generated once per completed run. If the summary generation fails, the run itself is unaffected — the summary is decorative, not load-bearing.
Per-bill results — which bills succeeded, which failed, and the reason for any failure
Retry action — for any failed bill, a retry CTA that attempts that single bill again without recreating the run

History

From the Payment Runs page, the History button opens the run history list. Each row shows:

Run date
Bill count and total amount
Status (completed, partial, scheduled, cancelled)
Who started the run

Click any row to open that run’s detail page. History is read-only — you cannot edit a past run, but you can retry failed bills from the detail page.

Audit Trail

Every Payment Run records the full audit context:

Who started the run
Which bills were included
Funding source configuration
Schedule (Pay Now or a specific date)
Idempotency key (for reconciling with your bank statement)
Timestamp of each state change (created, confirmed, processing, completed/partial/failed)

This makes it straightforward to tie a bank transaction back to its originating run during reconciliation.

Tips

Run on a cadence, not ad-hoc. A weekly or biweekly Payment Run on a fixed day gives vendors predictable payment dates and keeps your team in a rhythm.
Keep vendor defaults current. An out-of-date ACH routing number is the most common cause of a failed bill inside an otherwise-successful run.
Watch the concentration alert. If one vendor makes up most of a run, consider whether it belongs in a separate run with tighter review.
Schedule runs that have early-pay savings. The savings amount on Step 4 recomputes based on the scheduled date — moving a run forward a few days to catch a discount is often worth it.
Let the idempotency key do its job. If your network drops during Confirm, just click again. The server will not charge twice.

Common Issues

Issue	Cause	Solution
No bills available in Step 1	No bills are in Approved status	Approve at least one pending bill before opening the wizard
Early-pay column says “deadline passed”	The scheduled date is after the bill’s early-pay deadline	Move the schedule earlier on Step 3, or accept the full amount
Unresolved bills warning on Step 4	A bill you selected was deleted or archived mid-wizard	Remove the unresolved bill and continue, or return to Step 1
Partial completion (some bills failed)	Individual vendor payment routing issues	Open the run’s detail page and retry the failed bills from there
Draft not resuming	Draft save failed earlier (warning toast would have shown)	Start fresh; the draft could not be recovered
Can’t click Confirm	Selected bills include unresolved rows or a scheduled run is missing a date	Fix the flagged item; Confirm enables when the run is valid

Bills — Create, approve, and track the vendor bills that feed into a Payment Run
Expenses — The employee-reimbursement side of payables
Cash Flow — See how a scheduled Payment Run affects upcoming cash position
1099 Tracking — Contractor-payment reporting that draws from paid bills

Need Help?

If a Payment Run does not complete or a draft disappears unexpectedly:

Check the detail page — partial completions are normal and the detail view shows per-bill status
Verify the failed bills’ vendor payment methods are current
Check the audit trail for the exact timestamp of the failure
Contact support through the in-app help widget if a draft was lost or the run state looks wrong