The rows your export adds above and below the data.

You export last month from an ad platform to build the client report. The file opens fine. Before the column names there are three lines and a blank one, and after the last campaign there is one more line.

A CSV export has extra rows because it was laid out for a person to read, not for a program to import. The lines above the header say which report, account and dates the file covers. The line below the data adds everything up so you do not have to. They help whoever opens the file in a spreadsheet. Once a program reads the file as data, they change the numbers.

Here is a made-up export with both kinds of extra row:

Campaign performance
Account: Example Agency
Date range: 2026-08-01 to 2026-08-31

Campaign,Clicks,Cost,CPC
Brand search,4000,800.00,0.20
Spring sale,500,900.00,1.80
Retargeting,250,550.00,2.20
Total,4750,2250.00,0.47

Three campaigns spent 2,250 for 4,750 clicks.

Why does a CSV export have extra rows?

Because the platform wrote it for a reader, and a reader needs context a program does not.

The lines at the top are a label on the file. Without them, a CSV that sits in your downloads folder for a week is a grid of numbers with no account name and no dates. The line at the bottom is a courtesy: someone opening the file wants the total, and the platform has already computed it.

One survey platform's community forum has a thread from 2020 asking how to export without the three extra header rows the platform adds by default. The person asking deleted two of them by hand after every export. The answer was to submit a product idea, and the thread was still getting replies a year later.

The older reporting API of one of the largest ad platforms made the design explicit. It had three switches for a downloaded report: skip the row with "the report name and date range", skip the row with "the column names", and skip the row with the "totals". All three were off by default, so a report downloaded through that API came with the title row, the column names and the totals unless a developer asked otherwise. The defaults show what the platform counted as part of a report.

So the extra rows are a decision about who reads the file, and the file gets read by two audiences who want different things.

What happens when the rows above the header stay in?

The row that holds the column names is called the header. Everything under it is data. A program reading a CSV has to know which line is the header, and many tools assume it is the first one.

In our example, the first line is "Campaign performance". A tool that takes it as the header names the columns after the report title. The real column names, Campaign, Clicks, Cost and CPC, end up one row further down, sitting in the data as if they were a campaign.

The Clicks column should hold only numbers. Now it also holds the word Clicks. A column with a word in it stops being a column of numbers, so the total either fails or comes back as something you did not ask for. The account name and the date range become rows too, with most of their cells empty.

Some tools deal with this by dropping the lines they cannot make sense of, without saying which. That is quieter, and it leaves you with a table that looks fine and is missing whatever the tool decided was noise.

The usual fix is to tell the tool how many lines to skip. In our example that is four: three lines of banner and one blank. It works, as long as you check that the first row after the skip is a campaign and not a label.

Why is my total double?

The line at the bottom looks like a campaign. It has a label in the first column and numbers in the rest. Nothing about its shape says it is a total, and the label that gives it away changes from platform to platform and from language to language.

So when you add up the Cost column, the total line gets added too. Brand search, Spring sale and Retargeting come to 2,250. The total line says 2,250. Sum every row under the header and you get 4,500.

The clicks go the same way: 4,750 becomes 9,500. Every additive column in the report comes out at exactly twice the real figure.

Double is the lucky version, because someone who knows the account might notice that spend has doubled overnight. If the export also carries a subtotal for each campaign group, the error is no longer a clean multiple. It is some odd amount on top, and much harder to recognise.

A doubled number in a client report is the kind of mistake the client catches before you do. The client knows roughly what they spent last month. They have their own invoice from the platform.

Why can't you average a rate column?

The CPC column in our export is cost per click, a rate: cost divided by clicks.

The three campaigns have CPCs of 0.20, 1.80 and 2.20. Average them and you get 1.40. The account's real cost per click is total cost divided by total clicks: 2,250 divided by 4,750, which is 0.47. The average is three times too high, because it gives the tiny Retargeting campaign the same weight as Brand search, which had sixteen times the clicks.

A correct total line shows 0.47 in the CPC column, and in our export that cell is the only place where the rate has been computed from the totals.

Summing the rate column is worse still. The three campaign rows alone give 4.20. Include the total line and you get 4.67. Neither number means anything. The same goes for click-through rate, conversion rate, cost per acquisition and return on ad spend. Each one has to be recomputed from the totals; adding or averaging the rows gives a wrong number.

How do you use the total line before you delete it?

The total line is a checksum the platform hands you for free. Use it before you throw it away.

Add up the data rows yourself, without the total line, and compare your sum with it.

Your sum equals the total line. You have every row, and the line at the bottom is the total. Take it out and carry on.

Your sum is exactly twice the total line. You included the total line in your own sum. Take it out and add up again.

Your sum is some other amount. Rows are missing, or there are subtotals in the middle, or the platform computed its total over something your rows do not include, such as a filter or a rounding rule. Find out which before the number goes anywhere near a client.

Do this for an additive column like cost or clicks. For a rate column the check is different: divide the two totals yourself and compare the result with the rate on the total line. In our example, 2,250 divided by 4,750 gives 0.47, and the total line says 0.47.

How do you strip the extra rows every month?

In a spreadsheet the steps are simple. Delete the banner above the header, delete the total line, check your sums against the total line before you delete it, and check that the rows left are the campaigns you expect.

The trouble is that you do it again next month, and the month after, and the file is not always laid out the same way. A filter you added can show up as an extra line in the banner. The total line moves down as the number of campaigns grows.

Say September's export gains a line, "Filter: status is enabled", under the date range. The step that skipped four lines in August now stops one line early, on the blank line, and the tool reads a blank row as the header.

The platform will keep writing the banner and the total, because a person opening the file wants them. The report you build from it needs neither. Something has to sit between the two and decide, every month, which rows are the data.

How does Pressentable handle the extra rows?

In Pressentable, reading an export takes two steps. The first is a preview of the file as a grid, shown before a single number is read.

The preview marks the row it takes for the header. To pick it, a rule looks for the first row that is at least sixty percent as wide as the widest row in the file and holds only labels. That is what a row of column names looks like, and a banner line usually does not. The lines above that row are shown as skipped. In our example, the three banner lines and the blank line are marked as skipped, and the header starts at Campaign.

The rule is a judgement, and it will not be right on every file anyone can produce. If it picked the wrong row, you pick the right one, in the grid, before anything is read.

The same preview shows the bottom of the file, and that is where the total line comes out. You select the row and exclude it before anything in the report is bound to the data. In our example you would see the Total line under Retargeting and take it out there, in front of the actual rows, rather than by counting lines in a text editor.

Then the numbers are read, from the header down, without the rows you took out. Everything you build after that, a table, a chart, a figure in a sentence, reads from those rows and nothing else.

What happens next month?

The report keeps its header row, whether the rule found it or you set it, and it keeps it by what the row says rather than by where it was.

When next month's export arrives, the report does not look for the header on the same line number. It looks for the row that holds the same column names, Campaign, Clicks, Cost and CPC, wherever that row has moved to. If September's banner gained the filter line, the header is one line further down, and that is where the report finds it.

Here is the top of September's file:

Campaign performance
Account: Example Agency
Date range: 2026-09-01 to 2026-09-30
Filter: status is enabled

Campaign,Clicks,Cost,CPC

In August the column names sat on line 5. In September they sit on line 6. A step that skips four lines lands on line 5, which is now blank. The report looks for Campaign, Clicks, Cost and CPC and finds them on line 6.

We checked this with two files built the same way, the second with one more line of banner than the first. The report found the header one line further down in the second file, with nothing to correct.

Skipping a fixed number of lines breaks the month the banner changes length. The report stored the four column names instead, so the banner can grow, shrink or be reworded above the header and the header is still found.

If no row in the new file carries those column names, the report treats the file as a different file and reads it from scratch rather than forcing last month's answer onto it.

What should you check before the numbers go into a client report?

Four things, whatever tool you use.

Check that the first data row is a real record and not a label. If the first "campaign" in your table is called Account or Date range, the header is in the wrong place.

Look at the last data row. If it is called Total, Totals, Grand total or anything like it, take it out, after you have used it.

Compare one additive column with the total line before you delete it. Equal is good, double means the total is still in, and anything else means rows are missing or extra.

Make sure no rate column has been summed or averaged across rows. Cost per click, click-through rate and return on ad spend come from dividing two totals, never from adding or averaging the rows.

The client reports page shows what the product builds from the file after that, and the Northwind Cloud growth recap is a finished report for a sample client.