Cash Application rules that build themselves

Every finance team deals with a set of payment quirks. One customer always short-pays freight and settles it later. Another pays six invoices in a single wire on the 15th. A third references the PO number instead of the invoice number, every time. It is specific to your business, and it never shows up in a generic cash app matching model.

A recurring pattern like this belongs in a rule. A rule is deterministic: it fires the same way every time, it is easy to explain, and it does not drift. Writing rules is tedious, so most teams skip it and keep matching by hand.

Monk automatically suggests rules so your cash application can automate, without manual effort.

What is a cash application rule in Monk?

A cash application rule is a deterministic instruction that tells Monk how to match a specific, recurring payment pattern, with no LLM involved. Rules are the second of three tiers Monk uses for matching. They sit between fully automatic matches and the agent, and they exist for the cases your team recognizes on sight but that are too specific to leave to a model.

A rule captures that knowledge once and applies it to every future payment. Customer X's freight short-pay is handled the same way in July as it was in March. The batch payer's wire is split against the right invoices without anyone opening the transaction. The result is repeatable and auditable, which is what you want the moment financial data is involved.

How do suggested rules work?

You no longer author these rules from scratch. Monk reads the matches your team makes by hand, finds the patterns that repeat, and surfaces them as suggested rulesets.

The cash application page shows a metric card for your active rules with a direct call to action to turn on the ones Monk recommends. The rulesets page shows the full picture: your current rules next to the suggested rules, so you can review what Monk noticed and switch on the ones that fit. Every manual match your team makes becomes a signal. Monk proposes the rule, and you decide whether it goes live.

“The playbook and rule-building capabilities let us quickly identify what's driving delays and act fast, freeing up time for higher value projects,” said Eric Flores, Finance and Business Operations at Subject. Suggested rules take the last piece of manual effort out of that loop, so the rules keep building even on the weeks no one sits down to write them.

Why use a rule instead of the AI agent?

For a pattern you already understand, a prediction is the wrong tool. You do not want an 80% likely answer on a payment that follows a rule you could state in one sentence. You want the rule. It runs at full confidence, it does not get more or less sure depending on the week, and when someone asks why a payment matched the way it did, the answer is the rule you turned on, in plain language, with an audit trail behind it.

Showing our work is a core principle at Monk. Every match keeps its reasoning and a record you can review, and custom rules are the most transparent tier of all, because the logic is one you wrote or approved.

How rules fit Monk's three-tier architecture

Monk matches payments in three tiers, each with a different tolerance for risk:

• Tier one, deterministic matches. Full confidence, matched automatically, no LLM.
• Tier two, custom rules. Deterministic and specific to your business, now with Monk suggesting the ones to add.
• Tier three, the agent. A background agent runs daily over transaction and invoice data, handles the cases the first two tiers cannot encode, learns from every manual match, and improves over time.

Suggested rules make Tier two stronger without adding work. The more of your known patterns are encoded as rules, the more the agent is free to focus on genuinely new cases. Rules also perform best when each transaction carries its full detail, which is what uploading remittance restores.

Available now

Suggested rules and the rulesets page are live this week for Monk customers. Book a demo to see cash application in action.