Skip to main content

Matching and Coding Overview

Every expense goes through two steps before it can sync to your ERP. First it's matched: the receipt someone submitted is paired with the card charge that paid for it. Then it's coded: the fields your ERP needs to post it get filled in, some by Agave and some by a reviewer.

This guide is for admins. Read it before setting up profiles and policies, so you know which problems each tool solves.

How matching works​

Matching is automatic. Agave reads the receipt, finds card transactions that could be the same purchase, and attaches the one it's confident about. When it can't decide, the expense waits for someone to link it by hand.

Two rules shape everything else:

  • Only posted transactions are matched. A pending charge becomes matchable once the bank posts it.
  • The card's assigned user is the link. A card's charges are matched against receipts from the person set as its Assigned User on the Credit Cards page. A card with no assigned user and Match Txns to Any User? unchecked never matches anything.

A card transaction matches at most one expense.

How coding works​

Coding is partly automatic. A match fills in vendor, date, amount, and the ERP card and employee. A coding profile can fill in the accounting side. What's left, almost always the project and its budget line, is the reviewer's call.

Coding profiles carry no project. They're company-level, so applying one never picks the job for you.

Agave doesn't learn from corrections, so coding doesn't get more accurate on its own. It gets faster as you build out profiles and card defaults, because more of each expense arrives pre-filled.

Why the two steps are separate​

They fail differently. A matching problem means the wrong charge is attached, or no charge is. A coding problem means the right charge is attached to the wrong job or account. Knowing which one you're looking at tells you which guide to open.