agent classified the same bank fee three different ways across three runs and the variance report failed its check

TL;DR

Same input, three different classifications means the categorisation is being decided fresh each run - by a language model's judgement, an unordered rule list, or training examples that changed between runs - instead of by a stable mapping. Variance reports assume determinism, so they fail, correctly. Extract every occurrence of the fee from the three runs with its assigned category, then decide the one correct category with the finance owner and write it into a deterministic mapping keyed on the stable identifiers: bank descriptor, fee code and account. Reclassify the historical postings to that category so trends are comparable. Then constrain the agent: mapped descriptors must use the table, only genuinely new descriptors get judgement, and every new judgement is proposed as a table entry for approval rather than applied silently and differently next time.

agent classified the same bank fee three different ways across three runs and the variance report failed its check

Use this when

• The same recurring bank fee or charge appears under different expense categories in different agent runs.
• A variance or consistency check fails because category totals move without any real change in fees.
• The agent categorises transactions using judgement rather than a fixed mapping table.

Not for this skill when

• Finance deliberately changed the fee's classification by policy during the period. Document the change date and split the trend instead.
• The fees are actually different charges sharing a similar name. Separate them by fee code before mapping.

Steps

1. Pull every posting of the fee across the three runs with date, descriptor and assigned category, and total by category. Verify: the inconsistency is quantified and its exact occurrences are listed
2. Agree the single correct category for the fee with the account owner, referencing how the fee is analysed in reporting. Verify: one category is approved for the fee
3. Reclassify the historical postings that used the other categories, in the open period or by restating the analysis, per your reporting policy. Verify: history shows the fee in one category consistently
4. Write the descriptor-to-category mapping into the agent's deterministic mapping table and set mapped items to bypass judgement-based categorisation. Verify: the mapping entry exists and the agent's configuration references it
5. Add a stability check to the run: re-categorise a fixed sample of historical transactions and fail the run if any classification changes without a mapping change. Verify: the stability test runs and passes on the corrected setup

Variant phrasings

agent classified same bank fee three different ways runs variance failed

The non-determinism symptom.

deterministic mapping table bank fee categorisation agent stability

The mapping-table fix phrasing.

inconsistent transaction classification agent reclassify history fix

The history-repair search.

Compatibility: Agent categorisation over bank feeds in Xero, QuickBooks, NetSuite and custom reconciliation pipelines, with rule engines or model-assisted classification.

Why it happens

Judgement-based classification is probabilistic at the margins: a fee descriptor that sits between two plausible categories will flip depending on run context, neighbouring examples or model version, even at low temperature. Finance reporting, however, treats categories as facts and compares periods as if the classification rule were a constant. The clash is structural - a probabilistic step placed where the process assumes a deterministic one - and the cure is to move recurring items into explicit mappings and reserve judgement for the genuinely new.

Edge cases / pitfalls

• Near-duplicate descriptors (bank truncations, branch suffixes) need normalised keys in the mapping, or the same fee arrives as several keys.
• Any approved category change should version the mapping with an effective date so history can be restated or split deliberately.
• Sample stability tests catch model or prompt changes made outside the finance team's view.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpBCbXIs8uKEFWRT-SgUcw