Every invoice has a customer on it. Every bill has a supplier. Every bank payment usually turns out to belong to one or the other. Getting those records right — and keeping them from silently multiplying — is a smaller-looking problem than journal posting or VAT, but it's the one that most commonly makes an otherwise-correct ledger's reports misleading in practice.
One record type, not two disconnected lists
A counterparty is anyone on the other side of a transaction — a customer, a supplier, or sometimes both at once (a supplier you also sell to). Ac-co treats these as one underlying record type rather than two separate systems that happen to look similar, which means a single contact's full history — every invoice, every bill, every payment, in either direction — sits in one place. Ask "how much does this client owe us, and do we owe them anything back," and there's one record to look at, not two you have to reconcile against each other.
Why duplicate prevention is a bookkeeping control, not a UX nicety
The most common way a chart of accounts, and the reports built on it, quietly go wrong isn't a coding bug — it's a contact created twice. "Smith Builders Ltd" and "Smith Builders" look the same to a person glancing at an invoice, but to a report summing balances by contact, they're two separate debtors, each showing a smaller, individually-plausible balance instead of one correct, larger one. Multiply that across a client list built up over a few years and your Aged Debtors report can be meaningfully wrong without a single individual number being false.
Catching this at the point a new contact is created — checking against existing records before adding a new one — is far cheaper than the alternative, which is discovering the split months later and having to work out, transaction by transaction, which of the two records each one actually belongs to. When a duplicate does slip through, merging two contacts moves one's transaction history under the other rather than deleting anything, so the amounts on your historical invoices and bills stay exactly as they were.
Products and catalog items carry their own defaults forward
A product or catalog item is a saved line — a service or item you invoice or buy repeatedly — with a description, a price, and, critically, a default VAT treatment and nominal account. The point of saving it isn't convenience alone: it's that the VAT rate and the account a line posts to are decided once, correctly, and then reused every time that item appears on an invoice or bill, rather than depending on whoever's raising the invoice that day remembering the right rate and category from scratch.
That matters because VAT and account-coding mistakes on individual invoice lines are exactly the kind of small, repeated error that's invisible line by line but adds up to a real discrepancy in your VAT return or your P&L categorisation over a quarter.
What this looks like day to day
You won't usually think about any of this — you'll search for a customer, and either find the one you already have or be warned before creating a near-duplicate; you'll pick a saved product, and the VAT and account it posts to will already be right. Where it shows up is in the reports that depend on this being correct: an Aged Debtors list where each client appears once, at their real outstanding balance, and a VAT return where every invoice line was categorised the same way every time it was used — not because someone was careful, but because the record it came from only had one correct way to be entered in the first place.