Client Report Spreadsheet: Layout That Gets Read

A spreadsheet for a client report is a different document from the spreadsheet you did the work in. It opens on one tab, leads with the number the client is paying you to move, puts the previous period beside it, carries a notes column that explains anything odd before the client has to ask, and ends with a line saying where the numbers came from and when you pulled them. The working file stays on your machine. The report is a five-section deliverable: cover block, headline, detail, notes, method. Everything else you built to get there is yours.

There is no shortage of client tracker files in the world. They solve a different problem, which is keeping track of your clients, internally, for you. This is about the file that leaves your machine and lands in someone else's inbox, where you are not standing next to it to explain what column J means.

What does a client actually check first?

Three things, in this order: the number they are paying you to move, whether it went up or down, and whether they believe it.

That order is the whole design brief. It means the first thing on screen cannot be a filtered data table with 900 rows behind it, because a data table asks the client to do the analysis they hired you to do. It means the comparison has to sit next to the number rather than three columns to the right, because a number with no reference point produces a question instead of a reaction. And it means the third thing, belief, is bought with the least glamorous section of the file: the line at the bottom that says which account, which date range, and when you exported it.

Two facts about the reader change how you format. The first is that they will forward it. To a business partner, a bookkeeper, an ops manager, someone who was on none of your calls. Every label on the report tab has to make sense to that second reader, which rules out your internal abbreviations, a tab called Sheet1 (2), and any colour coding whose meaning lives in your head.

The second is that a decent share of first opens happen on a phone. You cannot control the render, but you can control the width. Keep the top block inside about six columns so the part that matters is not scrolled off the right edge of a mail preview.

If your reader is a client's leadership team rather than the client themselves, the summary-tab mechanics in how to present a spreadsheet to executives go deeper on which tab the file opens on and how many numbers survive the first screen.

How do you structure a report tab versus a working tab?

Two tabs minimum, and they take opposite rules.

The working tab is allowed to be ugly. Helper columns, raw exports, a column of notes to yourself, three versions of the same calculation while you worked out which one was right, filters still switched on. Nobody is grading it.

The report tab has one rule: nothing exists on it unless you can say what it is for in one sentence, to the client, without using the word "just". That single test removes helper columns, leftover ID columns, the row you left in to check a total, and the three metrics you track because your tool exports them rather than because anyone asked.

Here is the tab, section by section. Build it top down and it survives the questions.

The deliverable spec

Section	Where it sits	What it must contain	The client question it answers
Cover block	Rows 1 to 6, columns A to D	Client name in A1. Report title and scope of work in A2. Period covered, written out in full, in A3 (Reporting period: 1 to 31 July 2026). Prepared by, with your name and contact, in A4. Date the file was prepared in A5. Row 6 left blank as a spacer.	"What is this and what does it cover?"
Headline	Rows 8 to 12	One primary number in a large cell with its label directly above it, not beside it. Its unit stated in the label or the number format. Immediately to the right: the same measure for the previous period, then the change. Below it, at most three supporting numbers on one row, formatted identically.	"Did the thing I pay for happen?"
Detail	Row 14 down, one header row, one table, no gaps	The line items behind the headline. One row per unit the client thinks in: a channel, a project, a deliverable, a week. Every numeric column right aligned with the same number of decimals down the whole column. Header row bold, frozen, and repeated on print. No merged cells anywhere in it.	"Where did that number come from?"
Notes	The rightmost column of the detail table, wide, wrapped, left aligned	One short sentence per row that needs one, and blank for every row that does not. Anomalies, estimates, blocked work, anything a client would otherwise email you about. Plus a footnote block two rows under the table for caveats that apply to the whole report.	"Why is that one weird?"
Method	Two rows under the footnote block, small grey text	Source of each number, named specifically: the account, property, or system. The date and time you pulled the data. The definition of anything ambiguous, for example whether revenue is gross or net of fees. One line naming what is deliberately excluded.	"Can I check this?"

A reader who has that table can rebuild the tab from scratch. The parts people skip are the last two, and those are the two that determine whether the client asks a follow-up question or forwards it with "looks good".

One structural warning while you build it. Resist merging A1 across to F1 to centre the title. A merged block on a report tab breaks sorting, breaks filtering, breaks the copy and paste your client's bookkeeper is about to do, and is the single most common reason a clean-looking file falls apart in someone else's hands. Put the title in A1, make it bigger, and leave it. There is a fuller argument and the alternatives in the merged cells guide.

This is also the honest boundary of what a formatting tool can do for you, including ours. SuperSheet formats a tab that is already one clean table with one header row. It does not unmerge cells and it does not restructure a tab holding three stacked mini tables, because guessing at where one table ends and another begins is how a file gets silently wrecked. The structure above is your fifteen minutes. The finish is the part you can hand off.

Where do notes and caveats belong?

In the file, next to the number, and not in the email.

A caveat written in the email body has a lifespan of exactly one forward. The moment your client drags the attachment into a reply to their partner, your explanation of why week three looks thin is gone, and the number is left standing on its own looking like a problem. Everything you would put in the covering email that explains a figure belongs in the notes column instead.

Three rules make the column work rather than turn into clutter.

Blank is a signal. Only fill the note cell when a row genuinely needs one. If every row has a note, the client reads none of them. A column that is empty for eleven rows and full for one directs the eye better than any highlight colour.

Write the consequence, not just the observation. "Client portal was down 12 to 14 July" is an observation. "Client portal was down 12 to 14 July, so these three days are missing rather than zero" is a note that stops a reply. The second sentence is the one that took you the least time and saves the most.

Mark estimates with a symbol and a legend, not with a colour. Put a consistent marker in the note cell, define it once in the footnote block, and let it survive the two things colour does not survive: a black and white print, and a reader who does not distinguish your red from your grey. The spreadsheet accessibility checklist covers the wider version of that rule.

The footnote block under the table takes anything that applies to the report as a whole: a methodology change since last month, a date range that is short because of a holiday, a metric you have stopped tracking and why. Two or three lines. If it runs longer than that, it is not a footnote, it is a conversation, and it should be a call.

How should period-over-period comparisons be formatted?

Three columns, always in this order: this period, previous period, change. Right aligned, same number of decimals across all three, same unit down each column.

Label the comparison period with the actual period, not with a relative word. Jul 2026 rather than Last month, because the file will be opened in October by someone reconstructing what happened, and a relative label becomes a small lie the moment the file is archived. Same for the current column. The header row is where a report earns its second reading.

Two judgement calls that decide whether the comparison is useful or just present.

Absolute or percent. Show the absolute change by default and add the percent when the base is large enough for it to mean something. A percent change calculated against a base near zero is arithmetically true and practically useless, and clients quote it back at you. If last month was 2 and this month is 5, "up 3" is a report and "up 150%" is a story neither of you wants to defend.

Direction is not always good news. For cost per lead, refund rate, response time, or churn, a rising number is a worse number. If you use a convention where up reads as positive, you have inverted the meaning on half your rows. Either split those metrics into their own block with a stated convention, or drop the convention entirely and let a signed number and a plain-language note do the work. State whichever you chose in the footnote block, once.

On the mechanics of the number formats themselves, the sign display, the thousands separator, the alignment of a currency column so the digits line up, that is a separate subject with real syntax behind it. The Excel number formatting guide has the format codes and the four section grammar rather than repeating them here.

Should you send .xlsx or PDF?

Send the .xlsx when anyone on the client's side will do something with the numbers. Send a PDF when the report is the artifact of record. Sending both costs you one extra step and settles the argument permanently, so that is usually the right answer for a monthly.

The .xlsx is right when the client's bookkeeper needs to reconcile a column, when an ops lead wants to filter to one project, or when the numbers feed something on their end. Sending a PDF into that situation means someone retypes your figures, and retyped figures become wrong figures with your name on them.

The PDF is right when the report is being filed, attached to an invoice, forwarded to a board, or printed. It renders the same on every machine, which the spreadsheet does not. Microsoft's own guidance for saving or converting a file to PDF gives the paths: on Windows, File → Save As or Save a copy, then pick PDF (*.pdf) in the file type list. On Mac it is File → Save As or Save a copy, then File Format at the bottom of the dialog, then PDF. In Excel for the web there is no direct save, so you go File → Print and choose Save as PDF from the printer list. Worth knowing before you send: links pointing inside the workbook do not survive the conversion, so a "see detail tab" link in your summary becomes dead text in the PDF.

Set the page layout before you export rather than after you look at the mess, and repeat the header row on every page. On Mac that setting lives under Page Layout → Page Setup → Sheet → Print Titles → Rows to repeat at top; on Windows it is Page Layout → Print Titles. The full page setup pass is in exporting Excel to PDF without losing formatting.

What makes a report reusable next month?

The difference between a report you rebuild and a report you rerun is whether the report tab contains values or references.

Paste your export into the data tab and let the report tab point at it. The headline cell is a formula, not a typed number. The period label in the cover block is built from one date cell, so next month you change one cell and every header updates. The method line's "pulled on" date is a cell too, for the same reason. Every number you type by hand is a number you will forget to update, and the one you forget will be the one the client checks.

Three habits that keep it running:

• Make the detail range a real table so a longer month with more rows is picked up without you editing every formula.
• Keep a clean copy with no data in it, named as the template, and duplicate it each month. Never build next month by deleting this month's numbers out of the file you already sent.
• Put the period in the filename, not a version word. Acme-report-2026-07.xlsx tells everyone what it is a year from now. Acme-report-final-v3.xlsx tells nobody anything, including you.

Then apply the same visual treatment every single month. Consistency is doing quiet work here: when the file looks identical to the last four, the client stops evaluating the document and starts reading the numbers, which is the entire point of formatting it in the first place.

That last pass is the part worth automating. Drop the file into the Excel formatter, let it set the number formats, the header row, the freeze and the totals, apply the Executive theme from the template themes, and export. It is free, and nothing is uploaded anywhere. The file is processed in your browser and stays on your machine, which matters when the numbers belong to a client rather than to you.

Frequently asked questions

Should I send clients Excel or a PDF?

Send the .xlsx if anyone on their side will filter, reconcile, or reuse the numbers, because the alternative is somebody retyping your figures. Send a PDF when the report is the record: filed with an invoice, forwarded to a board, or printed. For a recurring monthly, attaching both is the low-friction answer. It takes one extra export and removes the question from your inbox for good.

How do I stop a client editing the numbers?

Inside a spreadsheet, you mostly cannot, and it is worth being clear-eyed about that. Excel's sheet protection sits on the Review tab as Protect Sheet on both Windows and Mac, and in Excel for the web under Review → Manage Protection. Microsoft's documentation on protecting a worksheet is explicit that this is not intended as a security feature. It stops accidental edits to locked cells, nothing more, and Microsoft cannot recover the password if you lose it. Note also that passwords in Excel for Mac are capped at 15 characters, so a longer one set on Windows will lock you out on a Mac. Google Sheets is the same story with different menus: Data → Protect sheets and ranges, and Google's help for protecting a sheet or range says plainly that it should not be treated as a security measure, since anyone with access can still print, copy, and export the data.

So if the real requirement is "these numbers must not change", the answer is a PDF, not a protected sheet. Use protection for what it is good at, which is stopping a well-meaning client from typing over a formula, and keep a copy of what you sent.

What should a report cover sheet include?

Five things, in the first six rows: the client's name, the report title with the scope of work it covers, the reporting period written out in full with both dates, who prepared it with a contact address, and the date it was prepared. That is enough for the file to identify itself a year later when it surfaces in a folder with no email around it. Anything else, logos, a summary paragraph, a table of contents for a two-tab workbook, is decoration competing with the headline number for the top of the screen.

How do I show data that's missing or estimated?

Never with a blank cell, because a blank reads as zero to about half of readers and as an oversight to the other half. Use a consistent marker in the notes column, define it once in the footnote block under the table, and write one sentence saying why the data is missing and what that means for the total. If a figure is estimated, say what it is estimated from. If a period is short because a system was down, say the days are absent rather than zero. A client who can see exactly which numbers are soft trusts the hard ones more, which is the opposite of the instinct to quietly paper over the gap.