Skip to content
Proofbell

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 needColumn names we recogniseRequired?
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 900123 and 07700900123
  • +44 7700 900123 and 447700900123
  • 0044 7700 900123
  • 01242 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:

  1. Our call ID, if your CRM stores it — certain, nothing inferred.
  2. A deal reference we have seen before — certain.
  3. An exact phone number match — high confidence.
  4. An email match — high confidence.
  5. 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

ReasonWhat 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.

Next All connections