Match accounts, effects and companies – Cost Control

Match accounts, effects and companiesCost ControlYou can resolve the three matching errors an import reports, and you know where unmatched lines end up.The import's **Preview** step reports what it could and could not resolve. It names three failures, and each has a different fix.| Message | What it means | Fix | | ------------------- | ---------------------------------------------------- | ---------------------------------------- | | **No such account** | the account number in that line is not in the budget | map it, or add the account | | **No such effect** | the effect name is not one the budget defines | map it, or add the effect in the budget | | **No such company** | the company name is not one the budget defines | map it, or add the company in the budget |A fourth, *Cannot read "name"*, is a column problem rather than a matching one — the mapping is pointing at a column that is not there. Check the column letters.No such accountThe commonest, and it has three causes:1. **A new account in accounting** that the budget does not have. Add it in the budget, then to the set. 2. **Numbering that does not agree** between accounting and the budget. The durable fix is to make them agree — see [set up an import mapping set](/kb/article/set-up-an-import-mapping-set). 3. **A one-off** — a booking that genuinely belongs somewhere else. Import it and move it afterwards.No such effect and no such companyBoth resolve the same way: either add the mapping in the mapping set, or add the effect or company to the budget so there is something to map to.Neither blocks the import. The line still comes in — it just arrives unclassified, which matters later when you group by effect or company and the figures are short.What happens to lines that cannot be matchedThe import does not refuse the file. It asks:*N cost items have no matching account and will be added under "Unmapped". Import anyway?***Unmapped is a real account** that appears in the set and stays there until somebody empties it. Nothing is lost, but nothing is right either — those costs are in the set and on no real account, so every affected account is understated.Continuing is the right call when you would rather have the data in and file it afterwards. Cancelling is right when the count is large, which usually means the mapping is wrong rather than the file.Clearing UnmappedOpen the [Cost Item List](/kb/article/work-with-the-cost-item-list), find the Unmapped items, select and move them — see [move cost items to another account](/kb/article/move-cost-items-to-another-account).Then fix the mapping, or next period parks the same lines in the same place.Markdown