What should a musician check before importing a transaction CSV into Clef?
Published · Updated · Clef
Before importing a transaction CSV into Clef, keep the original export, confirm the file’s account and period, and inspect the mapped dates, descriptions, and amounts. Review every error and any rows excluded from the import. Compare the result with the source file before retrying, so a partial import does not become a duplicate batch.
Which import workflow are you using?
Clef’s Import page separates Bank / Card CSV from Royalty Statement (DistroKid / Bandcamp). This guide covers the bank and card CSV mapper. A distributor earnings statement has different fields and a different review path; use the related royalty-payout guide when that is the evidence you are working from.
The CSV mapper has four stages: Upload, Map, Review, and Import. Choosing a file does not mean that its rows have already been committed. Use the preparation and preview stages to establish what the file contains before proceeding to the action that writes transactions.
Keep an untouched copy of the export and work on a separate copy if you need to reorganise it. Note the source account, currency, export date, period covered, and whether any of that period has already been entered. A filename alone is a poor way to resolve overlapping downloads later.
How should you check the header and column mappings?
The mapper treats the first CSV row as column headers. Remove report titles or other preamble from a working copy if they would be mistaken for the header, while retaining the original export. Check that the displayed header names actually correspond to the transaction data beneath them.
Date, Description, and Amount must be mapped before the Next control becomes available. Category and Notes are optional. The mapping stage shows the first three rows as a sample; that sample helps identify a misplaced column but cannot establish that every later row is complete.
| Mapping | What to compare with the source |
|---|---|
| Date | The actual transaction-date column, including its format and intended calendar date. |
| Description | The text identifying the payment or purchase, rather than a balance or reference-only column. |
| Amount | The transaction amount, not the running balance; check how the source represents signs. |
What can go wrong even when an amount looks plausible?
Look at representative positive and negative amounts, and at a value containing cents. The current mapper reads a numeric amount from the selected column and displays it to two decimal places in review. It does not ask you to map separate withdrawal and deposit columns. If your export uses that layout, prepare an appropriate single-amount working copy and verify the intended direction before continuing.
Use clear decimal values in the working file and compare the preview with the source convention. Do not assume that accounting parentheses, a trailing sign, or a localised number format will be interpreted the way your bank intends. A number can be readable and still mean the wrong thing.
Currency also needs a separate check. The bank/card mapping form does not include a currency selection, and its import request does not send one. The standard import route defaults to the workspace’s base currency when none is supplied. Do not treat this mapper as an automatic currency-conversion step for a foreign-currency export.
What would a small preview check look like?
Constructed example: a musician’s bank export has columns Posted, Details, Value, and Running Balance. The musician maps Posted to Date, Details to Description, and Value to Amount. One row describes a rehearsal-room payment with Value of -48.50, using an export convention in which withdrawals are negative.
Before importing, the musician checks that the review shows the intended date, rehearsal-room description, and -48.50. If the selected amount instead matches Running Balance, or the sign has changed, they go back to correct the mapping or working copy. They also inspect another row representing money received.
This is a preview exercise with invented data, not a record of a real customer or a claim that every bank uses the same sign convention. Keep a brief note of any transformations made to the working file so another reviewer can understand how it differs from the untouched download.
How should you handle rows with errors?
The Preview Import stage shows a total row count, an error count, and row-level date, description, amount, and error columns. The current client checks missing or invalid dates and amounts. Read the descriptions too; the absence of a displayed error is not a complete review of whether an entry describes the right event.
Skip rows with errors is selected by default. When it remains selected, the client excludes flagged rows from the submitted batch, and the Import button’s count reflects the rows it intends to send. Record which source rows are left out and why, rather than allowing an unexplained gap to disappear into a success total.
Go back and repair supported mistakes in the working file, or retain an exception list for items needing review. Do not invent a date or an amount simply to clear a validation message. CRA’s business-records guidance for Canadian sole proprietors and partnerships calls for identifiable income records supported by original documents; a convenient import format does not replace that evidence.
What should you verify after the import finishes?
The result stage displays an imported-transaction count and, where returned, failed-row messages. It also offers View Transactions. Compare the result with the number you intended to send and inspect the actual entries before deciding the batch is complete. Preserve the import outcome with the source and working files.
If only part of a batch is recorded, identify that subset before retrying. Do not assume that uploading the original file again will ignore entries already present. Prepare a controlled follow-up for unresolved rows instead of replacing a clear exception list with another full-file attempt.
Import review and reconciliation answer different questions. After you have established what was recorded, the related Clef bank-match guide covers comparing proposed transaction pairs with statement evidence. The digital-receipt guide covers filing supporting documents. Completing this CSV workflow alone does not establish that every transaction is reconciled or correctly classified for tax.
What else should I know?
Will an accepted date always mean the date I intended?
No. An ambiguous day/month ordering can be a plausible date without being the right one. Use an unambiguous working format such as YYYY-MM-DD, and compare the mapped result with the source record, especially where both the day and month could be valid.
Should I map a balance column when the amount column is missing?
A running balance and a transaction amount represent different information. Obtain the transaction-level values or prepare a supported working file rather than importing balances as individual payments.
Does importing a category decide the tax treatment?
A category label does not establish business purpose, deductibility, or GST/HST treatment. Keep the supporting documents and have uncertain classifications reviewed independently of the file import.
Is uploading a CSV to Documents the same operation?
No. The Documents page files documents through its own upload workflow. This guide covers the transaction CSV mapper on the Import page. Identify which outcome you need before selecting a file.