Turn the bill pile into coded entries and one payment decision.

Owners describe this job as printing, stamping, and hand-keying the same twenty invoices every month. It is almost entirely mechanical — right up to the part where money leaves the account, which is entirely the owner's call.

Pull from whatever the owner actually has:

Dedupe before doing anything else. The same invoice arriving as an email PDF, a vendor-portal reminder, and a statement line is three copies of one bill, and paying it twice is the failure this skill exists to prevent. See .

For every bill, pull: vendor, invoice number, invoice date, due date, terms, subtotal, tax, freight, total, PO number if present, and line detail.

A field you cannot read stays empty and gets named. A smudged total on a photographed invoice is reported as unreadable with the vendor and invoice number attached, never rounded to something plausible. Everything downstream — the coding, the payment run, the cash forecast — inherits whatever number lands here.

Code to the expense account, class, and job or customer using the owner's own chart of accounts and their history with that vendor. Past coding for the same vendor is the strongest signal available and should carry the decision most of the time.

Split-coding matters for contractors: one supply-house invoice often covers three jobs. Split it by line when the lines say so, and ask when they don't.

When the chart of accounts is not readable. Some ledger connections expose only sales and reporting tools, with no chart-of-accounts read. When that happens, propose account names from vendor history and common SMB charts, label every proposed code "unverified — confirm this account name exists in your books," and put those bills in the "needs your call" list rather than presenting them as matched.

Low confidence is a question, not a guess. A new vendor, an unfamiliar line, or a bill that could plausibly be COGS or overhead goes into an "needs your call" list with a suggested code and the reason. Read .

Where purchase orders exist, run the three-way match: bill against PO against receiving ticket.

Exception handling and tolerance guidance is in .

Present, in this order: total bills processed, total dollars, how many are clean, how many need a decision, and the named exceptions. Then the aging view — what is due this week, next week, and already late.

Lead with the dollar amount. That is the number the owner is deciding about.

Writing to the books changes the owner's financials, so it waits for an explicit yes.

State before asking: how many bills, the total dollar amount, which ledger they land in, and that they land as unpaid bills awaiting payment rather than as payments.

With NetSuite, QuickBooks, Xero, or Zoho Books connected, stage the bills there. But test the capability, not the logo: a connected ledger whose tools are read-only or sales/reporting-only cannot create bills. Zoho Books has no bill object — a bill already paid is recorded with (vendor, account, amount, date, ), and an open commitment with ; an unpaid bill awaiting payment cannot be staged there, so those go to the import file. When there is no bill-write access, say so in one line and fall to the same path as no ledger at all. Without a ledger connector — or without write access — produce a coded import file plus a plain summary the owner or their bookkeeper can key in — a complete outcome, not a consolation prize.

This is a second gate, not a continuation of the first. Approving the coding is not approving the spend, and treating it that way is how a plugin loses an owner's trust permanently.

Propose which bills to pay now, grouped by vendor, with:

Then ask. Say the total out loud before the question. The owner approves or trims the list; the skill never widens it.

Ramp can approve or reject a bill and mark it ready to sync to the ledger, so it is a genuine write path — which is exactly why it needs a rule.

The ledger stays the system of record. The connected ledger (NetSuite, QuickBooks, Xero, or Zoho Books) is where bills are staged and where the payment run is decided. Ramp's approve/reject and ready-to-sync calls are used only when the owner's bills genuinely live in Ramp and no ledger connector covers them, and they sit behind the same Step 7 payment gate as everything else.

Never run the AP flow through Ramp because it happened to answer first. A bill approved in Ramp and also staged in the ledger is the duplicate this skill exists to prevent, one layer up.

A vendor total is a net figure, and a net figure hides credits. Aging reports subtract credit memos, returns, and overpayments from what a vendor is owed, then show you only the remainder — while still reporting the whole amount as overdue.

The failure looks like this. A vendor shows a total of USD 911,404 and sits at the top of the overdue list. Underneath, that total is USD 2,411,404 genuinely past due against a USD 1,500,000 credit sitting in a different aging bucket. The report calls the vendor one hundred percent overdue. Ranked on the total, this vendor is the most urgent bill in the business. In reality nothing is owed until the credit is used up.

So before any vendor reaches the payment run:

A vendor whose buckets sum to zero or less is owed nothing this run. Say so and move on.

Disputes, missing invoices, and short-pay explanations get drafted, not sent. Write them in the owner's voice per the shared voice profile, state the invoice number and the specific discrepancy, and hold for approval like anything else that leaves the building.

Deliver the staged-bills report and payment proposal per the owner's stored output preference — never default to a markdown file. Check the block's (shared style guide rule, ):

The bills are read, coded, and staged, and the payment proposal is on the table. The natural next step is "pay the bills" — it adds the cash check before a dollar moves and carries the run to a staged payment. Also nearby: "cash forecast" to see what these payables do to the next 30/60/90 days, and "close the month" once the entries have landed. Offer at most three, and skip any offer the owner already declined this session.

The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.