Importing revenue
A call is worth knowing about. A call that became a £14,000 order is worth optimising for. Importing revenue is what turns Proofbell from a call log into something that changes what your ads buy.
What the file needs
A CSV export from your CRM. Column order does not matter and extra columns are ignored — we detect what we need and show you what we found before anything is saved.
| We need | Column names we recognise | Required? |
|---|---|---|
| A way to identify the person | Phone, Mobile, Contact Phone, Telephone, or Email | Yes — at least one |
| A deal reference | Deal ID, Record ID, Opportunity ID | Strongly recommended — see below |
| The value | Deal Value, Amount, Revenue, Total | No, but without it there is nothing to optimise on |
| When it closed | Close Date, Closed Date, Won Date | No — defaults to today |
| The outcome | Deal Stage, Status, Won | No — read from the stage text if present |
| Where the lead came from | Lead Source, Source, Event Type, Origin | No — but it is what lets you compare offline sources against your advertising |
Lead source, if you have one
We record six kinds of offline source: trade show, webinar, outbound (SDR), in store, lead form and inbound sales call. Ordinary spellings are read — "Trade Show", "Cold call", "Walk-in", "Contact form" all land in the right place, and so does a longer note like "Trade show — Birmingham NEC".
Anything we cannot place is stored as no source at all, and we tell you what it was. If your file says "Partner referral" we will not file it as the nearest match — that would put revenue in a bucket you did not choose, and nothing on any report would look wrong. The preview lists the values it could not place so you can decide whether to rename them or leave them unattributed.
A file with no source column at all is completely normal and produces no warnings. Nothing is assumed: those rows are recorded as offline conversions with no stated source.
Where you see it. The Pipeline screen carries a “Where these leads came from” table beside the channel table, showing what each source closed. It is also a column in the warehouse export, so you can group by it yourself — see warehouse sync.
The two tables on that screen are different views of the same revenue and must not be added together. A lead who came to your stand and also clicked an ad appears in full under Trade show and in shares across the channels. The reason they are separate tables rather than one is explained under attribution.
A minimal working example
Deal ID,Contact Phone,Deal Value,Close Date,Deal Stage
D-1001,07700 900123,"£12,500.00",03/07/2026,Closed Won
D-1002,+44 7700 900124,8000,15/07/2026,Closed Won
D-1003,01242 123456 ext 24,"1.234,56",20/07/2026,Closed Won Include a deal reference if you possibly can. It is how we recognise the same deal next time, so when a £2,000 quote becomes an £8,000 order you can re-import and the value updates rather than creating a second conversion. Without one we fall back to matching on the person plus the close date, which means two deals for the same customer on the same day merge into one.
Formats we accept
Phone numbers
All of these are understood, and extensions are stripped:
07700 900123and07700900123+44 7700 900123and4477009001230044 7700 90012301242 123456 ext 24,x24,#24
Numbers without a country code are read using the region you choose at import — so set it correctly if you have Irish or US customers in the same file as UK ones.
Watch out for Excel eating leading zeros. A UK mobile saved as a number
becomes 7700900123, and by then it is ambiguous. Format the phone column as
text before exporting. If a lot of rows fail to match, this is almost always
why, and the import report will say so.
Money
£12,500.00, 12500, $5,000, 2500 EUR,
(500) for a negative, and 1.2k all work. European decimals are
handled too: 1.234,56 is read as 1234.56, not 1.23.
Dates
ISO (2026-07-03) is unambiguous and preferred. Slash formats work, but
03/04/2026 is genuinely ambiguous — the 3rd of April in the UK, the 4th of
March in the US — so you choose the order at import and we tell you which we assumed. A
value above 12 settles it regardless.
How rows are matched to calls
In this order, stopping at the first that identifies exactly one person:
- Our call ID, if your CRM stores it — certain, nothing inferred.
- A deal reference we have seen before — certain.
- An exact phone number match — high confidence.
- An email match — high confidence.
- Last nine digits of the phone — medium. Survives formatting differences but can collide across countries, so it is counted separately and you can turn it off.
If a row matches two people, we do not guess. Shared switchboards, household lines and recycled mobiles are exactly where guessing does most damage — a £40,000 deal credited to the wrong campaign is worse than one left uncredited, because it is invisible. Those rows are reported as ambiguous for you to look at.
Nothing is saved until you say so
Uploading gives you a preview: the columns we detected, the match rate broken down by reason, and the revenue we could not attribute. Only then can you import.
That is not ceremony. Detection is a guess, and a file whose "Value" column is actually a lead score would push fabricated revenue into live bidding — damage that deleting rows afterwards does not undo, because the platform has already learned from it.
Reading the report
| Reason | What to do |
|---|---|
| Phone number could not be read | Usually Excel formatting, or the wrong region. Export the column as text. |
| No usable identifier | The column mapping is wrong. Check what we detected. |
| No tracked call from this person | They probably did not phone — a form fill or a direct enquiry. Not a fault, and worth knowing as a proportion. |
| Matched more than one person | A shared or recycled number. Needs a human. |
| Outside the lookback window | The call is older than the window allows. Raise it if your sales cycle is genuinely longer; otherwise these are recycled numbers and correctly excluded. |
Re-importing is safe
Import the same file twice and nothing duplicates — matched deals are updated in place. Only a deal whose value actually changed is re-sent to your ad platform, so a weekly export does not inflate your conversion count.
That covers the same file arriving twice. If the same sale reaches us from two different places — a spreadsheet and your CRM, or a CRM and your accounting system — see below, because that is a different question and we handle it differently.
When the same sale arrives from two places
Revenue can reach us from more than one source: a file you upload, a connected CRM, and in time your accounting or payment platform. Nothing stops one sale existing in two of them, and if we simply added them up your revenue — and the marketing credited with it — would be overstated.
So we look for records that describe the same sale, and what we do next depends on how sure we can be.
- When your own systems agree, we act on it. If an invoice quotes the deal reference, or both records carry the same order number, that is your systems saying they are the same thing — so the duplicate is left out of your totals and we tell you it was.
- When it is only a strong resemblance, we ask. The same customer, the same amount and the same week is usually one sale and sometimes genuinely two. We will not quietly remove revenue you earned on a resemblance, so the value stays in your figures and the pipeline report shows how much of it is in question. Two buttons settle each one.
Answer once and we will not ask again about that pair — including if you tell us they are two separate sales.
The one thing worth doing at your end: if your systems share a reference — an order number, a job number, a quote number — put it in a column. That turns every guess into a certainty, and it is the difference between us removing a duplicate for you and us asking you about it.
Name the column one of these, because that is how we recognise it:
Order number, Order no, Order ID,
Invoice number, Invoice no, Job number,
Quote number, Purchase order, PO number,
Sales order, Your reference, Our reference, or
External reference.
A column called simply Reference is not picked up, and that is deliberate
rather than an oversight: CRM exports use that heading for their own internal record ID at least
as often as for an order number, and feeding record IDs into the one check that merges revenue
without asking would delete sales you actually made. Rename the column and it works.
One more thing about the reference itself: it has to look like an identifier rather than a
counter. INV-88 or JOB-2026-4417 is fine. A bare 1000 is
not — two systems both numbering from one will produce the same value for completely different
sales, and merging those would delete revenue you earned. Short numbers are still imported;
they just do not remove a duplicate on their own, and the preview tells you so.
One limit, stated plainly: we compare amounts exactly. If your CRM holds a deal at £1,000 and your invoice shows £1,200 including VAT, we will not spot that they are the same sale unless they share a reference. We would rather miss one than merge two real sales and quietly delete revenue you earned.
We also warn you if you upload a file byte-identical to one already imported, in case it was not what you meant.
How often
Weekly is plenty for most businesses. Google accepts offline conversions within 90 days of the click, so as long as your import runs comfortably inside that, nothing is lost. If your sales cycle regularly exceeds 90 days, tell us — that needs a different approach.