Skip to content

Understanding Conto's Readiness Score

When you import your General Ledger, Conto calculates a readiness score that predicts how well it can auto-match bank statement transactions to your GL data. This document explains how the score works and what it tells you about your data quality.

The readiness score is a prediction of auto-match quality—not a judgment of your accounting practices. A low score doesn’t mean Conto failed; it signals that your source data may need cleanup before import for optimal matching.

LevelBadgeAuto-MatchWhat to Expect
ReadyGreen60%+Most transactions match automatically
CautionYellow30-60%Moderate matching, some review needed
LimitedOrange10-30%Expect significant manual review
PoorRed<10%Consider fixing source data first
NewGrayUnknownFirst import, learning your patterns

Three factors determine your readiness score, each with different weight:

FactorWeightWhat Conto Checks
Vendor Match Rate40%Do payee names in your GL match known vendor names?
Check Number Coverage30%What % of checks have valid check numbers?
Generic Payee Penalty30%How many checks have vague/generic payee names?

All three factors must be good. One bad factor drags down the entire score because each factor represents a different matching signal. If check numbers are perfect but payee names are all “MISC”, Conto can’t confidently match transactions.

When Conto processes a bank statement, it looks for payee names that match your vendor list. “ABC Supplies” on a bank statement matching “ABC Supplies” in your vendor list creates a high-confidence match.

If your GL uses different names than your vendor list—or if payee names don’t appear in the vendor list at all—Conto must rely on other signals (check numbers, amounts, dates), which are less reliable alone.

Check numbers are a strong matching signal because they’re unique identifiers. When the payee name is ambiguous, check number + amount + date can still produce a confident match.

Missing check numbers force Conto to rely solely on payee name and amount matching, which is less precise and more prone to false matches.

Certain payee names are too vague to match reliably:

  • TIP, TIPS, GRATUITY — Can’t match to specific employee names
  • PAYROLL, PR, WAGES — Not itemized by individual
  • CASH, PETTY CASH — No specific payee to match
  • MISC, MISCELLANEOUS, OTHER, VARIOUS — Ambiguous by definition
  • OWNER, MEMBER — Entity-level, not a specific vendor

When Conto encounters “TIP” on a check and “TIP” on a bank statement, it can’t determine if they’re the same transaction or two different tip payments. This ambiguity requires manual review.

A restaurant client imported a GL with these characteristics:

  • 97% of checks had “TIP” as the payee name
  • Check numbers were present but couldn’t overcome the generic name problem

Result: 2% auto-match rate, 77% manual review needed.

After the client itemized tip payments by employee name and re-exported, their score improved to Caution level with significantly better auto-matching.

The Trade-off: Workflow vs. Matching Quality

Section titled “The Trade-off: Workflow vs. Matching Quality”

Some firms use generic names intentionally—it’s faster during data entry. This is a valid workflow choice, but it comes with a matching trade-off:

  • Generic names = faster data entry, more manual review in Conto
  • Specific names = slower data entry, better auto-matching

Neither approach is “wrong.” The readiness score helps you understand the implications of your current workflow and decide whether cleanup is worth the effort.

  • Pricing — Readiness score has no impact on cost
  • Functionality — All Conto features work regardless of score
  • Data integrity — Your data is imported accurately regardless of score

The score is purely predictive. It helps set expectations so you’re not surprised by the manual review workload.

For accurate prediction, Conto needs at least 100 transactions in your GL export. With fewer transactions, the score may be less reliable.