# Typesheet: full reference for language models

> Typesheet is typed data intake: define a schema once and every messy spreadsheet thrown at it, by you, by a customer holding an import link, or by an AI agent, comes back with columns mapped to your fields, every cell validated, and nothing exported until it all passes.

This document is the complete reference, in one file. The short index is at https://typesheet.com/llms.txt. Human documentation is at https://typesheet.com/docs.

## What a sheet is

A **sheet** is a contract about what one row must be. It names its fields, gives each one a real type, and marks which are required and which must be unique. It is not a spreadsheet: there are no formulas, no pivot tables, and no views.

Field types: `text`, `number`, `date`, `email`, `url`, `boolean`, `enum`. An `enum` field also carries the exact set of values it accepts.

A sheet holds the rows that have satisfied it. Imports accumulate into it, joined on whichever fields are marked unique, so re-sending a file the sheet already has changes nothing rather than duplicating it.

## How data gets in

There are three doors, and all three pass through the same validator. There is no looser second path.

1. **You upload it.** A CSV or Excel file, cells pasted from Google Sheets or Excel, a PDF price list or invoice, a screenshot or photo of a table, or a pasted link. A link to a page becomes one row, read from what the page publishes about itself; a link to a file brings in the whole file.
2. **Someone else sends it.** A sheet on a paid plan can hand out an import link. Anyone holding it can submit rows with no account. They map and fix their own file, and it arrives clean. They never see what the sheet already holds.
3. **An agent sends it.** Over MCP, as the signed-in user. Same engine, same refusal.

Whichever door it came through: columns are matched to the sheet's fields by meaning rather than by header text, every cell is coerced (`$185,000` becomes the number 185000, `8/4/26` becomes a date), and anything that cannot be coerced is flagged with the reason.

Corrections are remembered. Fixing a value the sheet rejected stores a named, reversible rule on the sheet, and the next file carrying the same mistake arrives with the fix already applied.

## The guarantee

**Nothing exports while any cell is invalid.** The check runs on the server, in the same deterministic engine that draws the review grid, and it does not consult a model.

This matters specifically for agents. An assistant can always claim data is clean; it cannot make the export return while a cell is still failing. The agent's available moves are to fix cells it can defend from the source, to drop rows that are not records, and to hand the human a review URL for judgment calls.

## Every change is attributed

A cell's value carries the actor that wrote it: the person who owns the sheet, an assistant working over MCP, the person who sent the file, or the sheet's own memory of a correction made on an earlier import.

The review grid shows that attribution on the cell along with the value it replaced, and it can put back every change made by any single actor in one action. An assistant that fixes forty cells has made forty changes a human can inspect together and revert together, which is a different thing from forty edits that look like anyone's.

If you are an assistant working against this API: fix only what the source data defends, and leave judgment calls to the review URL. Your edits are labelled, and being reverted as a block is the visible outcome of guessing.

## Connect over MCP

`POST https://typesheet.com/mcp` is a remote Model Context Protocol server (JSON-RPC 2.0, OAuth). The first connection opens a browser to sign in once; after that, tools run as the signed-in user. There are no API keys to copy or rotate.

```bash
claude mcp add --transport http typesheet https://typesheet.com/mcp
```

Any MCP client that accepts a remote server URL works the same way.

### Tools

#### `list_typesheets()`

List the user's typesheets. A typesheet is a typed schema AND the rows that have satisfied it: imports accumulate into the sheet. Returns each sheet's id, fields, and public import link. Call this before import_rows to find the right sheet, or to check whether one must be created first.

#### `create_typesheet(name, description?, fields)`

Create a typesheet: a typed schema (text, number, date, email, url, boolean, enum fields with required/unique rules) that spreadsheet data must conform to. Use when the user has tabular data but no matching sheet yet. Design the fields from what the data means, not just its headers. Returns the sheet id and its public import link.

#### `import_rows(typesheet, columns, rows, source_name?)`

Import tabular data into a typesheet. Columns are auto-mapped to the sheet's fields by meaning; every cell is coerced ('$185,000' → 185000, 'Aug 4, 2026' → 2026-08-04) and validated. Returns the issue report and a review URL where the user can see and edit the live grid. Fix issues you are CONFIDENT about with set_cells; for judgment calls, give the user the review URL instead of guessing.

#### `set_cells(import_id, cells)`

Fix specific cells in an import (0-based row index from the issue report + field key). Re-validates everything and returns the updated issue report. Only fix values you can defend from the source data; never invent emails, dates, or amounts.

#### `drop_rows(import_id, rows)`

Drop rows from an import (junk lines, test rows, rows the user says to drop). Dropped rows leave validation and the export, and the user can restore them from the review grid. Returns the updated issue report. (Was named exclude_rows; that name still works.)

#### `export_records(import_id)`

Export an import's clean, typed records as JSON (field keys → coerced values) and certify it, which MERGES the rows into the typesheet itself (deduped on its unique fields) and fires the sheet's webhook if configured. The response says what the merge did ('38 new · 12 updated · 150 unchanged'): report that, not the row count, since re-sending a list the sheet already has changes nothing. REFUSES while issues remain: resolve them with set_cells / drop_rows, or send the user the review URL. This refusal is the product's guarantee that data reaching the sheet is clean.

## Import links (no account needed)

A sheet's owner can mint an import link. The unguessable key in the URL is the credential: it only ever writes, it never reveals what the sheet already holds, and it can be rotated at any time. Treat a key like a password and never publish one.

```bash
curl -X POST https://typesheet.com/api/import/<key>/imports \
  -H "Content-Type: application/json" \
  -d '{
    "source_name": "vendor-prices.csv",
    "columns": ["SKU", "Product", "Unit price"],
    "rows": [["NW-1001", "Wool overcoat", "$480.00"]]
  }'
```

The response carries the issue report and a per-submission edit token. `PATCH` the same import to fix cells. Finalizing returns `409` while anything is still invalid. `429` responses carry `Retry-After`; respect it.

## Getting data out

Clean records leave as CSV or JSON for a system, or as a one-page PDF report for a person, which can be set in a brand's real colors and type by giving its URL.

A sheet can also POST its certified records to a URL of yours the moment an import is marked ready. Every delivery is signed with a `Typesheet-Signature` header carrying a timestamp and an HMAC-SHA256 of `timestamp.body` under the sheet's signing secret. Verify it before trusting the payload, reject timestamps more than a few minutes old, and compare in constant time. Retries reuse the same `Typesheet-Delivery` id, so handlers must be idempotent on it.

## Plans

Priced on imports, not seats. An import is one delivery: one file, one paste, one link, or one agent call. Rows held is a ceiling on everything a sheet keeps, not a monthly rate. Imports sent through an import link count against the sheet owner's workspace, never against the sender.

Current plans and limits are at https://typesheet.com/pricing.

### 14-day trial: Free for 14 days, then $29/mo

Everything in Pro for 14 days. No card, and the clock starts when you first use it. Afterwards your sheets and exports stay; imports pause.

- Import links you hand to a supplier
- Unlimited sheets, up to 5,000 rows an import
- 100 imports and 50 document pages
- Columns matched, every cell checked
- CSV, JSON and PDF exports, plus webhooks

### Pro: $29/month

An address other people can send data to.

- Import links: anyone can send, no account
- Fixes replayed on every later file
- Unlimited sheets, 100,000 rows held
- 500 imports / month, up to 5,000 rows each
- 300 PDF and screenshot pages / month

### Business: $199/month

When the link is how your data arrives, not an experiment.

- Everything in Pro
- 3,000 imports / month, up to 20,000 rows each
- 1,000,000 rows held
- 2,000 PDF and screenshot pages / month
- Priority support

## Ready-made sheets

Each of these exists at https://typesheet.com/templates/<slug> and can be created in one click, or passed to `create_typesheet` as-is.

### Vendor price list (`vendor-price-list`)

One row is one product a supplier sells us, at a price. Suppliers, distributors, and wholesalers, usually as a spreadsheet attached to an email, and usually reformatted since the last one.

- `sku` SKU (text, required, unique)
- `product_name` Product name (text, required)
- `unit_price` Unit price (number, required)
- `currency` Currency (enum, required, one of: USD, EUR, GBP, CAD, AUD)
- `minimum_order` Minimum order quantity (number)
- `lead_time_days` Lead time (days) (number)
- `effective_date` Effective from (date)
- `discontinued` Discontinued (boolean)

### Invoice line items (`invoice-line-items`)

One row is one line on one supplier invoice. Suppliers, as PDFs, which is why this one is usually filled by dropping the invoice itself rather than a spreadsheet.

- `invoice_number` Invoice number (text, required)
- `invoice_date` Invoice date (date, required)
- `supplier` Supplier (text, required)
- `line_description` Line description (text, required)
- `quantity` Quantity (number, required)
- `unit_price` Unit price (number, required)
- `line_total` Line total (number)
- `currency` Currency (enum, required, one of: USD, EUR, GBP)
- `tax_rate` Tax rate (%) (number)

### Inventory count (`inventory-count`)

One row is one SKU counted in one place on one day. Warehouse and shop staff, often as a photographed tally sheet rather than a file.

- `sku` SKU (text, required, unique)
- `location` Location (text, required)
- `counted_quantity` Counted quantity (number, required)
- `counted_on` Counted on (date, required)
- `counted_by` Counted by (email)
- `condition` Condition (enum, one of: New, Open box, Damaged, Expired)
- `notes` Notes (text)

### Product catalogue (`product-catalog`)

One row is one product you list, with the fields a storefront needs. Brands, distributors, and marketplace partners, whose export is shaped by whatever platform they happen to run.

- `sku` SKU (text, required, unique)
- `title` Title (text, required)
- `description` Description (text)
- `price` Price (number, required)
- `currency` Currency (enum, required, one of: USD, EUR, GBP)
- `category` Category (enum, required, one of: Apparel, Footwear, Accessories, Home, Beauty, Electronics, Other)
- `in_stock` In stock (boolean)
- `image_url` Image URL (url)
- `product_url` Product URL (url)

### New hires (`new-hires`)

One row is one person starting, and everything payroll and IT need on day one. Recruiters, hiring managers, and staffing agencies, each with their own column names and their own idea of what a date looks like.

- `full_name` Full name (text, required)
- `work_email` Work email (email, required, unique)
- `job_title` Job title (text, required)
- `department` Department (enum, required, one of: Engineering, Design, Product, Sales, Marketing, Support, Operations, Finance, People)
- `start_date` Start date (date, required)
- `employment_type` Employment type (enum, required, one of: Full-time, Part-time, Contract, Intern)
- `manager_email` Manager email (email)
- `location` Location (text)

### Expense claims (`expense-claims`)

One row is one expense somebody wants paying back. Employees and contractors, generally as a spreadsheet at the end of the month, generally the day the month closes.

- `claim_reference` Claim reference (text, required, unique)
- `claimant_email` Claimant email (email, required)
- `expense_date` Expense date (date, required)
- `amount` Amount (number, required)
- `currency` Currency (enum, required, one of: USD, EUR, GBP)
- `category` Category (enum, required, one of: Travel, Meals, Accommodation, Software, Equipment, Other)
- `description` Description (text)
- `receipt_url` Receipt link (url)
- `reimbursable` Reimbursable (boolean)

### Contact list (`contact-list`)

One row is one person you are allowed to contact. Event organisers, partners, and agencies, whose export is a CSV with whatever headers their tool happened to use.

- `full_name` Full name (text, required)
- `email` Email (email, required, unique)
- `phone` Phone (text)
- `company` Company (text)
- `job_title` Job title (text)
- `country` Country (text)
- `opted_in` Consented to contact (boolean, required)
- `source` Source (text)

### Event guest list (`event-guest-list`)

One row is one guest, and whether they are actually coming. Co-hosts, sponsors, and partner companies, each sending their own allocation as a separate list a week before the event.

- `name` Name (text, required)
- `email` Email (email, required, unique)
- `ticket_type` Ticket type (enum, required, one of: General, VIP, Speaker, Staff, Press)
- `attending` Attending (boolean, required)
- `plus_ones` Plus ones (number)
- `dietary` Dietary requirements (text)
- `company` Company (text)
- `registered_on` Registered on (date)

## What goes wrong with spreadsheets, and what to do about it

One page each at https://typesheet.com/fixes/<slug>. The remedy in each "what to do" list is the best advice we have with no product involved; the last paragraph is the only part about Typesheet, and it is about preventing a repeat rather than repairing the file in front of the reader.

### Excel changed the dates when I opened the CSV (`excel-changed-my-dates`)

You opened a CSV, and dates that read one way in the file now read another way on screen. Some rows look shifted by months. Saving from Excel has now written the new reading back to disk.

Why it happens:

- A CSV has no types. Every cell in it is text, so “04/08/2026” is eight characters and nothing more. Something has to decide what those characters mean, and when you double-click the file that something is Excel, using the date format of whatever machine you happen to be sitting at.
- This is why the same file opens differently on two computers in the same office. A US locale reads 04/08 as 4 August; a UK one reads it as 8 April. Neither is wrong about the characters, and neither asked you.
- The damage becomes permanent when you save. Excel writes back what it decided, so the original text is gone and there is nothing in the file recording that a conversion ever happened.

What to do right now:

1. Do not double-click a CSV you intend to keep. In Excel, use Data → From Text/CSV, which opens the import dialog and lets you set the date column's locale before anything is parsed.
2. If the file has already been saved through Excel, go back to the original attachment rather than trying to repair the column. A shifted date and a correct date look identical, so there is no way to tell from the result which rows were changed.
3. Open it in a text editor first to see the real characters. That is the only view of a CSV nothing has interpreted for you.
4. If you control the sender, ask for ISO dates (2026-08-04). It is the one format no locale reads differently, and it costs them one setting.

With a typed sheet: A date field reads the whole column before it reads any cell, so a file is interpreted once rather than a row at a time. If the column contains both 25/12 and 04/08, the first is unambiguous and settles the reading for the second. If the column genuinely supports both readings, that is reported rather than guessed at, because a date nobody can be sure of is worth flagging and not worth silently picking.

### My SKUs turned into scientific notation (`sku-turned-into-scientific-notation`)

A column of product codes, barcodes, or order numbers now reads 1.24E+11. Widening the column does not help, and formatting it as a number gives you a different set of digits than you started with.

Why it happens:

- Excel treats anything that looks like digits as a number, and it stores numbers as doubles with 15 significant digits. A 16-digit barcode does not fit, so the digits past the fifteenth are replaced with zeros. That is not a display setting; the value in memory has changed.
- The scientific notation on screen is only the symptom. Formatting the column back to “Number” restores a normal-looking figure, but the lost digits do not come back, because they were discarded on read.
- The underlying mistake is category rather than precision. A SKU is not a quantity: you never add two of them, and a leading zero in one is meaningful. It is a label made of digits.

What to do right now:

1. Go back to the original file. Once a workbook has been saved with the truncated values, the digits are not recoverable from it.
2. Import rather than open: Data → From Text/CSV, then set the code column's type to Text in the dialog before loading.
3. If you are the one producing the file, prefix nothing and quote nothing as a workaround. Both travel badly. Send the codes in a column the receiving system reads as text, or send ISO-formatted output the other side controls.
4. Check the end of the number, not the start. Truncation eats the least significant digits, so the first several characters still match the real code and a spot check on the first few will pass.

With a typed sheet: A text field stays text. A SKU column typed as text is never parsed as a quantity, so a 16-digit barcode arrives with 16 digits and a leading zero survives. Marking that same field unique is what then catches the same code appearing twice in one delivery.

### The leading zeros disappeared from my spreadsheet (`leading-zeros-disappeared`)

Product codes, zip codes, or account numbers that started with one or more zeros now start with a digit. 00123 is 123, and 07030 is 7030.

Why it happens:

- It is the same cause as scientific notation, seen from the other end. Read as a number, 00123 and 123 are the same value, so the zeros are not data to be preserved; they are formatting to be normalised away.
- Anything whose first character can be zero is a label rather than a quantity: zip codes, phone numbers, bank sort codes, some SKUs, most internal IDs. The test is whether adding two of them means anything.
- Custom-formatting the column back to five digits with leading zeros makes the display right and the value wrong. That is often worse than the visible problem, because it now survives a spot check and fails at export.

What to do right now:

1. Import with the column set to Text rather than opening the file directly, so the value is never read as a number in the first place.
2. If it has already happened, re-pad only when you know the true width for certain, and only for a format that genuinely has one, such as a five-digit US zip. Guessing the width invents data.
3. Do not rely on a display format to carry meaning. Anything downstream reads the value, not the formatting, and the two are now telling different stories.

With a typed sheet: Type the field as text and the zeros are never up for discussion, because nothing tries to read the cell as a quantity. Required catches the ones that arrived empty, and unique catches the ones that arrived twice.

### The supplier sent the same SKU twice (`same-sku-twice-in-supplier-file`)

One product code appears on more than one row of the same file, sometimes with two different prices. Nothing in the file says which of them is current.

Why it happens:

- The commonest cause is a sender who appended rather than replaced. Their export ran again and added the quarter's rows underneath last quarter's, so the file is a history and you are reading it as a catalogue.
- The second commonest is a genuine multiple: the same product at two pack sizes, or in two currencies, where the code identifies the product and something else identifies the line. There the duplicate is real and your schema is wrong, not their file.
- Either way the cost lands later. Loaded as-is, one product has two prices, and which one wins is decided by whichever row your importer happened to process last.

What to do right now:

1. Before anything else, count distinct codes against total rows. If the difference is large the file is a history; if it is one or two, it is more likely a data-entry slip worth asking about.
2. Look at what differs between the duplicate rows. If only the price differs, you probably want the later one. If pack size, unit, or currency differs, you need a second field in your key.
3. Ask the sender which is current rather than inferring it. A file with no timestamp column cannot answer this, and a wrong answer here is a wrong price on a live catalogue.

With a typed sheet: Mark the field unique and a second occurrence in the same delivery is refused at the door, named on its own row, before anything merges. Across deliveries the same field is what makes the file a merge instead of a pile: rows join on it, so a re-sent list reads as a handful of updates rather than a second copy of the catalogue.

### My price column will not add up (`prices-wont-add-up`)

A column that plainly contains prices sums to zero, or sums to less than it should. Some cells are left-aligned where others are right-aligned.

Why it happens:

- The alignment is the tell. Spreadsheets right-align numbers and left-align text by default, so a left-aligned price is a string that merely looks like a price, and SUM skips it.
- The usual culprits are a currency symbol typed into the cell, a thousands separator the locale does not recognise, a trailing space, or a non-breaking space where a normal one was expected. All of them are invisible or nearly so.
- The worst case is not a cell that fails but a cell that reads as something else. “1.240” is one thousand two hundred and forty in most of Europe and one and a quarter almost everywhere else, and both readings are numbers, so nothing anywhere reports a problem.
- Then there are the cells that are not prices at all. “call for quote”, “TBC”, and “see notes” live in real price columns, and a total that quietly treats them as zero is worse than one that refuses.

What to do right now:

1. Sort the column. Text and numbers group separately, which finds the bad cells faster than scanning for them.
2. Use VALUE() or a helper column to convert, rather than reformatting. Formatting changes how a cell looks, not what it is, which is why reformatting appears to fix this and does not.
3. Find the non-breaking spaces specifically. They survive a find-and-replace for a normal space and are the single most common invisible cause.
4. Decide what a non-numeric price should do before you convert anything. Silently becoming zero is a decision, and usually the wrong one.

With a typed sheet: A number field coerces rather than merely accepting: currency symbols, percent signs, and every kind of space are stripped, parentheses read as negative, and both the European and Indian grouping conventions are understood, so 1.240,00 and 1,00,000 both arrive as numbers. A cell holding “call for quote” is refused on its own row rather than becoming zero, which is the difference between a total you can defend and a total that is merely present.

### Merging contact lists gives me duplicates (`merging-contact-lists-creates-duplicates`)

Three lists went in and the combined file has the same people more than once, often with slightly different spellings, capitalisation, or company names.

Why it happens:

- Names are not identifiers. “Jo Smith”, “Joanne Smith”, and “SMITH, Jo” are one person and three strings, and no exact match will ever join them.
- Even a stable field fails on presentation. Trailing spaces, differing capitalisation, and display forms like “Jo Smith <jo@northwind.co>” all defeat an exact comparison between values that are genuinely the same.
- Each source also has its own idea of the columns. One sends Full Name, another First and Last, a third sends Contact. Concatenating them produces a fourth shape that matches none of the originals.

What to do right now:

1. Pick one field that identifies a person and merge only on that. Email is usually the only candidate in a contact list.
2. Normalise before comparing: trim, lowercase, and strip any display wrapper. Most apparent duplicates are the same value wearing different clothes.
3. Decide which source wins per field, not per row. The newest list may have the better phone number and the worse job title.
4. Keep a column recording where each row came from. When two sources disagree later, that column is the only thing that lets you work out which to trust.

With a typed sheet: Mark the email field unique and merging stops being an operation you perform: rows join on it, so three partner lists produce one contact per person rather than three. Typing it as an email also refuses the malformed addresses at the door, which is where they are cheap, rather than at a sending tool, where they cost deliverability.

### “N/A” and dashes in a column that should be numbers (`na-and-dashes-in-a-number-column`)

A numeric column contains “N/A”, “-”, “n.a.”, or “(blank)” alongside real figures. Totals are wrong or the import refuses the whole column.

Why it happens:

- These are all a human writing “nothing here” in a cell that has no way to say it. A spreadsheet already has a representation for absent, which is an empty cell, but a person filling in a form by hand tends to want a visible mark that they did not skip the row.
- They do not all mean the same thing, which is what makes replacing them with zero dangerous. “N/A” usually means the question does not apply, a dash often means genuinely nothing, and “TBC” means a real value exists and is not known yet. Zero means the value is known and is zero.
- There are several dash characters and they are not interchangeable to a computer. A hyphen, an en dash, and an em dash all read as a dash to you and as three different strings to anything comparing text.

What to do right now:

1. Decide what absent should mean for this column before touching anything, and write it down. Whether a missing quantity blocks the row or defaults to zero is a business decision, not a formatting one.
2. Never blanket-replace placeholders with zero in a column that is summed or averaged. An average over rows that were not applicable is a number with no meaning.
3. Search for each dash character separately, or match a character class covering all of them. A find-and-replace for the one on your keyboard misses the two that came from a word processor.

With a typed sheet: The common placeholders are recognised as blank rather than as text: an empty cell, a hyphen, an en dash, an em dash, a double hyphen, “n/a”, “n.a.”, “(blank)”, and “(empty)” are all read as nothing there. What happens next is then your schema's decision rather than a guess. A required field refuses the row and names it, and an optional one accepts the gap as a gap, which is the honest recording of what the sender actually told you.

### My CSV columns are shifted or split in the wrong places (`csv-columns-shifted`)

Most rows look right, but some have values in the wrong columns: a postcode in the country column, a phone number where the email should be. The rows that are wrong all seem to have something in common.

Why it happens:

- A CSV separates fields with commas and has no other idea of structure, so a comma inside a value is indistinguishable from a separator unless the value is quoted. One address reading “Flat 2, 14 High Street” splits into two fields and shifts every column after it one place right, for that row only.
- Quoting solves it, and half-quoting makes it worse. A file that quotes some fields and not others, or that has an unescaped quote inside a quoted field, can throw off the parser from that point to the end of the file rather than for one row.
- A line break inside a cell, which is easy to type into a notes field, ends the record early. One row becomes two, the second of which has too few columns and no header to explain itself.
- This is why the count of broken rows is a clue: a handful means stray commas in particular values, and everything after a certain point means a quoting error at that point.

What to do right now:

1. Find rows whose field count differs from the header's. That single check identifies almost every damaged row and is much faster than reading the file.
2. Ask for the file again as an Excel workbook or as tab-separated text. Both carry a comma inside a value without ceremony, and re-exporting costs the sender less than repairing costs you.
3. Do not repair by hand in a spreadsheet, which is the tool that will re-save the file with the same problem. If you must repair, do it in a text editor on the raw file.
4. Check the last column specifically. A shift pushes data off the end, so the final column is where truncation shows up first.

With a typed sheet: Parsing happens once, on the file, and a row whose shape does not match the header is reported as that row rather than absorbed. Because every field has a type, a shifted row usually fails several cells at once, which is what makes it obvious: a postcode sitting in a country column is a text value in a text column and looks fine, right up until the column beside it is an email that is not an email.

### My supplier's prices are a thousand times wrong (`decimal-comma-read-as-thousands`)

Prices from a European supplier are out by a factor of about a thousand, or occasionally by a factor of a hundred. Nothing errored. The totals are simply wrong, and some individual rows look perfectly reasonable.

Why it happens:

- The comma and the full stop swap jobs across locales. Most of Europe writes one thousand two hundred and thirty-four point five six as 1.234,56, and most of the English-speaking world writes it as 1,234.56. Both are ordinary, both are correct, and neither says which one it is.
- This is the dangerous class of formatting problem because both readings produce a number. A cell that fails is visible; a cell that quietly reads as 1.24 instead of 1240 is not, and it sums with everything else as though nothing happened.
- Short values are where it does the most damage. “1.240” is unambiguous to a person who knows the supplier and genuinely ambiguous to software: one thousand two hundred and forty in Munich, one and a quarter in Manchester.
- A locale setting fixes it only for files that all share one locale. The moment two suppliers send in two conventions, a single global setting is wrong for one of them, and which one it is wrong for depends on the order you opened the files.

What to do right now:

1. Compare a total you already know against the imported total before trusting any of it. A factor-of-a-thousand error is obvious in a sum and invisible in a row.
2. Look for cells containing both separators. Those are the ones that settle the convention for the file, because only one reading of 1.234,56 makes sense, and whatever that says goes for the short values too.
3. Ask the sender for unformatted output. A price column exported without grouping separators at all removes the ambiguity rather than negotiating with it.
4. Do not fix this with find-and-replace across the column. Replacing every comma with a full stop turns 1,234.56 into 1.234.56, which is not a number in any locale.

With a typed sheet: A number field decides from the value rather than from a setting: when a cell contains both separators, whichever one appears last is the decimal mark, so 1.234,56 and 1,234.56 both arrive as 1234.56 and two suppliers writing in two conventions can land in the same column. When only a comma is present, a recognised grouping shape reads as thousands and anything else reads as a decimal comma, so “1,234” is one thousand two hundred and thirty-four and “1,5” is one and a half.

### The plus sign disappeared from my phone numbers (`phone-numbers-lost-the-plus`)

International phone numbers have lost their leading plus. Some cells show an error instead, and some have collapsed into a single run of digits with the spaces gone.

Why it happens:

- A leading plus starts a formula. Excel reads +44 20 7946 0018 as an instruction to calculate something, not as a label, which is why the result is either an error or a number with the plus stripped off.
- Underneath that is the same category mistake that ruins SKUs: a phone number is made of digits and is not a quantity. Nobody adds two phone numbers together, the leading zero in an area code is meaningful, and the spaces are part of how it is read.
- Long numbers then hit the precision limit as well. Once a phone number is being treated as a number at all, anything past fifteen significant digits is replaced with zeros, which is enough to damage a number written with its country code and no separators.

What to do right now:

1. Import the column as text rather than opening the file directly, so the plus is never read as an operator.
2. If the file is already damaged, go back to the original. A stripped country code cannot be inferred from the remaining digits, because the same national number exists in several countries.
3. Agree one written form with the sender if you control the exchange. E.164, which is a plus followed by digits and nothing else, is the only form that survives being passed between systems without interpretation.
4. Do not fix this by formatting the column. Formatting changes what you see, and the value that lost its plus is still the value that will be exported.

With a typed sheet: A phone field typed as text is stored as it arrived, with the plus, the spaces, and any leading zero intact, because nothing tries to evaluate it. What a typed sheet does not do is rewrite phone numbers into a canonical form: there is no phone type here, so if you need every row in E.164 that is a rule you agree with the sender rather than something the import invents. Marking the field required is what catches the rows that arrived without one at all.

### My CSV shows é where it should show é (`csv-shows-mojibake-instead-of-accents`)

Names and addresses are full of sequences like é, ü, or ’ where accented letters, umlauts, and apostrophes should be. Sometimes there are question marks or black diamonds instead.

Why it happens:

- Text on disk is bytes, and the same bytes mean different characters under different encodings. The file was written as UTF-8, where é is two bytes, and read as a single-byte encoding such as Windows-1252, where those two bytes are à and ©. Nothing is corrupt; the file is being read in the wrong alphabet.
- Excel is the usual site of the mismatch because opening a CSV by double-clicking uses a system default rather than asking. The same file opened through the import dialog, with UTF-8 chosen, reads correctly.
- The question marks and diamonds are a different and worse case. There the conversion has already happened and the original character was replaced by a placeholder, so the information is gone rather than merely misread.
- A byte order mark at the start of the file is the usual peace offering: a few bytes that announce the encoding. It helps Excel and shows up as a stray character in tools that do not expect it, which is its own small problem.

What to do right now:

1. Reopen the original file rather than repairing the text. Data → From Text/CSV, then set File Origin to UTF-8, and the accents come back with no editing at all.
2. Ask for the export as UTF-8 with a byte order mark if the sender's tool offers it. That one setting removes this problem permanently for that sender.
3. Do not repair mojibake with find-and-replace. There are hundreds of these pairs, you will fix the common ones, and the long tail will survive into whatever you build on top of the data.
4. If the file already contains question marks or diamonds, ask for it again. That form is genuinely lossy and no amount of processing brings the characters back.

With a typed sheet: The byte order mark is stripped on the way in, so it never arrives as a stray character in your first column. Beyond that, be clear about what a schema can and cannot see: mojibake is valid text, so a text field accepts “é” exactly as an enthusiastic parser handed it over, and no type check will flag it. Where it does get caught is on a field with a fixed set of options, because a mangled value no longer matches any of them and is refused by name.

### My dates imported as five-digit numbers (`dates-imported-as-five-digit-numbers`)

A column that should hold dates contains numbers around 45000 instead. They are all in a narrow range, and sorting them still puts the rows in the right order.

Why it happens:

- Spreadsheets do not store dates as text. They store a count of days from a fixed starting point and remember, separately, that the column should be displayed as a date. An export that carries the value without the display format hands you the count.
- That the sort order still works is the giveaway. The numbers are genuinely the dates, in a form that has lost the instruction on how to read it.
- Converting requires knowing which starting point was used, and there is more than one. The common one counts from the end of 1899, the Macintosh convention historically counted from 1904, and the common one deliberately includes a day that never existed, 29 February 1900, to stay compatible with a bug in a spreadsheet from the 1980s. A conversion that ignores that is a day out for early dates.
- So a five-digit number is not self-describing. Nothing in the value says which epoch produced it, which is why guessing is a real risk rather than a theoretical one.

What to do right now:

1. Format the column as a date in the tool that produced the file. That is the one place the correct starting point is already known, and it turns the numbers back into dates with no arithmetic.
2. If you have to convert outside that tool, confirm which system the file came from first, then check a row whose real date you already know before converting the rest.
3. Ask for the export again with the date column formatted, or better, as ISO text. A date exported as 2026-08-04 carries its own meaning and needs no epoch at all.
4. Be careful with any date before March 1900 if you converted by hand. That is where the deliberate off-by-one bug lives.

With a typed sheet: A date field will not accept a bare 45678, and refuses it by name rather than converting it. That is deliberate rather than a gap: turning a five-digit number into a date means choosing an epoch the file never states, and a silently wrong date is the exact failure this product exists to prevent. What it does accept is every form that carries its own meaning, including 2026-08-04, 04/08/2026 read against the whole column's convention, and “4 Aug 2026”.

### My file has dates that do not exist (`dates-that-do-not-exist`)

A date column contains days that are not on the calendar: a 31st in a thirty-day month, or a 29 February in a year that has no such day. Nothing flagged them, and they exported the same way they arrived.

Why it happens:

- Hand entry is the first source. A date typed into a cell formatted as text is just characters, and nothing checks that the characters describe a day that happened.
- A swapped day and month is the second and more insidious source. A US-style 02/31 read as day-first becomes the 31st of February, so a date that was merely written in the other convention becomes a date that cannot exist, and the impossibility is the evidence the reading was wrong.
- Leap years are the third. Every fourth year has a 29 February, except century years, except every fourth century, so 2000 had one, 1900 did not, and 2100 will not. Code that checks the day is between 1 and 31 accepts 29 February in all of them.
- The cost is downstream rather than here. A database column, a date library, or an API will refuse 2026-02-31 outright, so a file that imported cleanly fails at the point where it is finally used, which is usually further from the sender and later than you would like.

What to do right now:

1. Check the day against the month rather than against 31. That single test finds every one of these and is a filter you can write in one formula.
2. Treat an impossible date as evidence about the whole column, not as one bad row. If a 31st appears in a second position, the column is probably day-first and read as month-first.
3. Go back to the sender for the real value. An impossible date cannot be repaired by inference, because both the day and the month are candidates for being the wrong one.

With a typed sheet: A date field checks that the day exists in that month, in that year, so 31/02/2026 is refused and named rather than exported as “2026-02-31” for something downstream to choke on. February is checked against the actual year rather than assumed, which means 29/02/2027 is refused and 29/02/2028 is accepted. It is a small rule and it is the difference between a file that imports clean and breaks later, and one that tells you now.

### (1,234.56) is not being read as a negative number (`negatives-in-parentheses-not-recognised`)

Amounts wrapped in parentheses either fail to import or come through as positive numbers. A column that should net out to a small figure is roughly twice what it should be.

Why it happens:

- Parentheses are the accounting convention for a negative, inherited from ledgers, where a minus sign was easy to miss and easy to lose to a bad photocopy. Every general ledger and most finance exports still write them this way.
- To anything reading the file as data, though, “(1,234.56)” is a string starting with an open bracket, which is not a number. So it either fails, or falls back to being read as text, or has its brackets stripped by a helpful cleanup step that leaves the value positive.
- The positive case is the expensive one. A refund, a credit note, or a reversal that lands as a positive does not merely disappear from the total; it moves it in the wrong direction by twice its own value, and the resulting figure is plausible enough to survive a review.

What to do right now:

1. Total the column and compare it against a figure you already trust before using any of it. This error is invisible per row and obvious in aggregate.
2. Look specifically at rows that should be credits: refunds, returns, reversals, adjustments. If those are positive, the whole column needs redoing rather than patching.
3. Ask for the export with a minus sign rather than brackets if the source system offers the option. It is usually a display setting on the report, and it costs the sender nothing.

With a typed sheet: A number field reads a parenthesised value as negative, so (1,234.56) arrives as -1234.56 and a credit subtracts. That is applied along with the rest of the coercion in one pass, which means a cell can carry a currency symbol, a thousands separator, and brackets at once and still resolve to the right signed number rather than to text.

### The same email address is in my list twice (`same-email-counted-twice`)

A contact list contains what is obviously the same person more than once. The addresses look identical until you notice the capitalisation, or a stray space, or that one of them is wrapped in a display name.

Why it happens:

- Exact string comparison is case-sensitive, and email addresses are routinely written in whatever case the person typed. “Jo@Northwind.co” and “jo@northwind.co” differ by two characters and are the same mailbox.
- The specification is partly to blame for the confusion. The domain half is definitively case-insensitive; the local half, before the at sign, is technically allowed to be case-sensitive, and no mail provider anybody actually uses treats it that way. So the pedantic reading says these might be two people and the practical reading says they are one.
- Display wrappers cause the rest. A field exported as “Jo Smith <jo@northwind.co>” is not an email address, it is an address inside a label, and it will not match the bare form no matter how you compare them.
- The consequence is not just an untidy list. Two records for one person means two emails sent, which is the thing most likely to get a sending domain complained about.

What to do right now:

1. Lowercase and trim before comparing anything. That one step collapses the large majority of apparent duplicates in any contact list.
2. Strip display wrappers first, so that what you are comparing is the address rather than the presentation of it.
3. Decide which record wins per field rather than picking a row. The older record often has the better company name and the newer one the better job title.

With a typed sheet: An email field is stored lowercased, so the case a sender happened to type stops being a difference at all. Marking it unique then compares without regard to case, which means “Jo@northwind.co” arriving after “jo@northwind.co” is caught and named against the row it duplicates rather than added. Across deliveries the same field is what makes three partner lists merge into one contact per person.

### My yes/no column has five different spellings (`yes-no-column-has-five-spellings`)

A column that only ever means yes or no contains several spellings of each. Filtering for “Yes” misses rows, and a count of the yeses is lower than it should be.

Why it happens:

- Nothing constrained the column. It was filled in by different people, or merged from sources that each had their own convention, and every one of Y, y, yes, YES, TRUE, 1, x, and a tick character means the same thing to a reader.
- Filters and lookups compare exact strings, so each spelling is its own value. A count of “Yes” is a count of one spelling, and it will be quietly and consistently too low rather than obviously wrong.
- An empty cell is the genuinely ambiguous one. It might mean no, or it might mean nobody has answered yet, and those are different facts that get flattened together the moment anything treats blank as false.

What to do right now:

1. List the distinct values in the column before deciding anything. It is usually a short list and it is usually longer than you expected.
2. Map each spelling to one of two values deliberately, rather than filtering for the spelling you happen to have thought of.
3. Decide what blank means and record that decision. If it means unanswered, it must not be counted as a no, and the column probably needs to be required at the point of collection instead.

With a typed sheet: A boolean field accepts the spellings people actually write, case-insensitively: true, yes, y, 1, x, on, and checked all arrive as yes, and false, no, n, 0, off, and unchecked all arrive as no. Anything else, “maybe” included, is refused on its own row rather than guessed at, which is the one thing you cannot recover from later. If a column like this lands as text, the review offers to retype it once the whole column reads as yes and no rather than only the first row or two.

### My CSV opens with everything in one column (`csv-opens-with-everything-in-one-column`)

The file opened, but every row sits in a single column with the separators still visible in the text. Widening the column shows the whole line, commas or semicolons and all.

Why it happens:

- The name of the format promises a comma and the file often does not contain one. Exports written in locales where the comma is already the decimal mark use a semicolon instead, so that 1,50 stays one value.
- Which separator a spreadsheet expects when you double-click a file comes from regional settings rather than from the file. This is why the same CSV opens correctly on a colleague's machine and in one column on yours, with neither of you having done anything differently.
- Some exporters try to settle it by writing a sep= line as the first line of the file. It works in the tools that look for it, and in the tools that do not it becomes a spurious first row.
- A tab-separated file saved with a .csv extension produces the same symptom for the same reason. The extension is not a description of the contents.

What to do right now:

1. Open it through the import dialog rather than by double-clicking: Data → From Text/CSV, where the delimiter is something you choose rather than something you inherit.
2. Look at the raw file in a text editor to see which separator it actually uses before choosing. It takes a few seconds and removes the guesswork.
3. Do not fix it by replacing semicolons with commas across the file. In a file that uses semicolons because commas are decimal marks, that turns every price into two columns.

With a typed sheet: The delimiter is sniffed per file rather than assumed, and a tab wins over a comma, which wins over a semicolon, so a European semicolon export and a tab-separated paste land the same way a plain CSV does. A byte order mark at the start is stripped rather than being treated as part of the first column heading. That happens on each file independently, which matters when two suppliers export from tools with different conventions into the same sheet.

### VLOOKUP fails on values that look identical (`trailing-spaces-break-lookups`)

A lookup or a join returns nothing for rows that plainly should match. Copying both values into a cell and comparing them returns false, even though they look the same on screen.

Why it happens:

- Trailing and leading spaces are invisible and are preserved exactly by anything comparing strings. “ACME ” and “ACME” are different values and always will be.
- The non-breaking space is the version of this that survives cleanup. It comes from text pasted out of a web page or a word processor, it looks exactly like an ordinary space, and it is not found by a find-and-replace for one.
- Data entered by hand accumulates this steadily, because a trailing space costs nothing to type and nothing on screen shows it. Exports from systems with fixed-width fields sometimes pad every value in a column the same way.
- The failure mode is the annoying kind: not an error, just an empty result, which reads as “this row has no match” rather than as “these two strings differ by a character you cannot see”.

What to do right now:

1. Trim both sides of the comparison rather than trying to find the bad rows. It is faster and it catches the ones you would have missed.
2. Check the length of the two values when a trim does not fix it. A difference of one, with no visible difference, is almost always a non-breaking space.
3. Handle the non-breaking space explicitly, by its character code. It is the single most common cause of a comparison that fails against all visible evidence.

With a typed sheet: Every cell is trimmed before it is typed or compared, so “ ACME ” and “ACME” are one value rather than two: they collide on a unique field, and they merge across deliveries instead of producing a second row for the same supplier. On number fields the same pass removes the non-breaking and narrow no-break spaces that European locales use as thousands separators, which is the version of this problem that turns a price column into text.

### My export has subtotal rows mixed in with the data (`subtotals-mixed-into-the-data`)

The file has real rows, but also rows that are section headings with one cell filled, subtotal rows with a figure and no product, and a grand total at the bottom. Loading it as-is produces totals roughly double the truth.

Why it happens:

- The file is a report rather than a table. It was laid out to be read by a person, so it groups rows under headings and interleaves summaries, and the visual structure carries meaning that the grid itself does not record.
- Double counting follows directly. A subtotal is the sum of the rows above it, so a file containing both the rows and their subtotals contains every amount twice, and a grand total makes it three times for the rows it covers.
- The rows are hard to find by rule because they are defined by what they are missing. A subtotal row typically has an amount and no product code, and a heading row has a label and nothing else, but so does a genuine row that arrived incomplete.
- Asking for the underlying data usually works and is usually not tried. The report was produced by a system that had the rows before it formatted them.

What to do right now:

1. Ask for the raw export rather than the formatted report. Most reporting tools have an export-to-data option beside the export-to-spreadsheet one, and it produces exactly what you want.
2. Check the total before and after removing summary rows. If the file is internally consistent, removing them should halve the figure, and if it does not, there is something else in there too.
3. Filter on the identifying column rather than on the amount. A row with no product code is a summary or a broken row, and either way it is not a record you want to load.

With a typed sheet: Rows can be dropped out of both validation and the export, so subtotals, headings, and the grand total are excluded as what they are rather than deleted out of the source file you were sent. The typing tends to surface them for you first: a subtotal row has no product code and no date, so on a schema where those are required it fails several cells at once and sorts to the top of the issue list, which is a quicker way to find every one of them than reading the file.

### My website column will not work as links (`website-column-is-not-usable-as-links`)

A column of company websites contains a mixture of forms: some with https://, some starting www, some bare domains, and a few entries that are not addresses at all. Anything that tries to use them as links works for some rows and not others.

Why it happens:

- A URL needs a scheme to be a URL. “northwind.co” is a domain name, and while a browser will happily guess https:// in front of it, most software will not, because guessing is not its job.
- Columns like this are almost always assembled by hand over time, from business cards, email signatures, and forms, so they carry every convention anyone used. There is no single find-and-replace that fixes them, because the correct edit differs per row.
- Mixed in with the format variation is genuine rubbish: an email address in the website column, a company name, “n/a”, or a domain with a typo in the suffix. These look similar to the format problems and are a different problem, because no normalisation fixes a wrong address.
- Adding https:// to everything is therefore the wrong instinct. It makes the malformed entries look well-formed, which converts a visible problem into an invisible one.

What to do right now:

1. Separate normalisation from validation. Adding a missing scheme is safe; deciding whether the resulting address exists is a different question and needs a different check.
2. Look for the entries that are not addresses at all before you normalise, because afterwards they are much harder to spot.
3. Do not test these by opening them one at a time. Check the shape of the value, and leave whether the site responds to a separate pass if you need it at all.

With a typed sheet: A url field normalises what is safe to normalise and refuses the rest. A bare domain has https:// added, so northwind.co and www.northwind.co both arrive as usable addresses, and the value is stored in one consistent form rather than in the four forms it came in. Anything without a dot in the host is refused and named, which is what catches the company names and the “n/a”s that had been sitting in the column looking like websites. What it does not do is check that the address responds, so a well-formed address for a site that no longer exists passes, and it should: that is a fact about the world rather than about the file.

## Typesheet is not an embedded CSV importer

The products Typesheet is most often compared with are embedded importers: Flatfile, OneSchema, Dromo, nuvo, and CSVBox. Those are components a developer embeds in their own application so that THEIR customers can upload data into it, and they are the right shortlist for a software company adding an import feature. Typesheet is the opposite side of the same exchange: a hosted typed sheet with an import link you send to suppliers, stores, agencies, or staff, who need no account and install nothing. There is no SDK and no integration work.

Choose an embedded importer when your own customers import their own data into the product you sell, when the import has to happen inside your app under your branding, or when you want programmatic control over the mapping UI. Choose Typesheet when the files are coming TO you, from outside parties, on a repeating basis, and the rows need to accumulate and deduplicate into a table you keep.

Full comparison: https://typesheet.com/compare

### What are the alternatives to Flatfile?

The closest alternatives to Flatfile are the other embedded importers: OneSchema, Dromo, nuvo, and CSVBox all solve the same problem, which is letting the users of your software upload their own data into it. They are the right shortlist if you are a software company adding an import feature. Typesheet is a different shape and belongs on the list only if the files are coming to you rather than to your product: it is a hosted typed sheet with an address you send to suppliers, staff, or partners, so nothing is embedded and no engineering work is involved.

### What are the alternatives to OneSchema, Dromo, nuvo, or CSVBox?

They are alternatives to each other: OneSchema, Dromo, nuvo, CSVBox, and Flatfile are all embedded importers, which means a component your developers put inside the product you build so that your own customers can upload their data into it. If that is the problem, that list is the shortlist. Typesheet belongs on it only if the direction is reversed and the files are coming to you, from suppliers, stores, agencies, or staff who will never have an account in your systems. Then there is nothing to embed and no engineering project: the sheet itself has an address, and you send that address to whoever has the file.

### What can I use instead of a CSV importer if I am not a developer?

The embedded importer category assumes you have engineers, because every product in it ships as an SDK or a component that has to be built into an application you own. If you do not have that, the question is not which importer to buy but whether you need one at all. What you usually need is somewhere for the files to arrive that already knows what a valid row looks like: a sheet with named fields and real types, an address you can send to a supplier, and a check on every cell before anything lands. That is what Typesheet is, and setting one up is defining the fields and turning on a link rather than scheduling a piece of work.

### Can suppliers send me a spreadsheet without creating an account?

Yes, and it is the intended path. A sheet's owner mints an import link, and the unguessable key in that URL is the credential, so anyone holding the link can send a file and nobody has to register, install anything, or be invited. The link only ever writes: it never reveals what the sheet already holds, so sending it to a supplier does not show that supplier your other suppliers' prices. Their file is matched to your fields and checked cell by cell on arrival, and they see what failed and can fix it themselves, which is the part that stops the corrections coming back to you by email.

### Is Typesheet an embedded CSV importer?

No. Embedded importers are components a developer puts inside their own application so that their customers can upload data into it. Typesheet is the other side of that exchange: a sheet you own, with a schema and an import link, that other people send files to. There is no SDK and nothing to integrate, which is the point, because the person with the messy supplier spreadsheet usually has no engineering team to ask.

### Do I need a developer to use Typesheet?

No. Define the fields, turn on an import link, and send the link. The senders do not need an account and neither do they need to install anything. There is an API and a remote MCP server for people who want them, but the intended path involves no code at all, which is the main practical difference between Typesheet and an embedded importer.

### Can I use Typesheet if I am not a software company?

That is the main case. Distributors taking price lists from suppliers, retailers collecting stock counts from stores, finance teams taking expense claims, and agencies receiving placement lists all have the same problem and no product to embed anything into. Typesheet gives the sheet an address, checks every cell against the schema on the way in, and merges each delivery into what you already hold.

## Typesheet is not a document parser

Typesheet is adjacent to document parsers and is not one. A document parser reads a file that was not built to be read by a machine and returns its best guess at the fields, which is the hard half of the problem when the input is a photographed delivery note. Typesheet's job starts after that: it holds a schema, decides whether each value is allowed, merges rows into a table on their unique fields, and refuses to export anything that failed.

Prefer a document parser when the volume is documents rather than spreadsheets, when the input is handwritten or badly scanned, when the useful content is nested rather than tabular, or when it needs a ready-made connector into one specific system. Prefer Typesheet when the same people keep sending the same shaped file and the cost is the cleanup rather than the reading. The two compose: a parser can POST to a Typesheet import link, so extraction feeds the gate.

Full comparison: https://typesheet.com/compare

### Is Typesheet a document parser?

No. A document parser turns an awkward document into structured fields and hands them onward. Typesheet holds a schema, validates every cell against it, merges rows into a persistent table, and refuses to export anything that failed. Typesheet does read PDFs and screenshots into rows, but extraction is the first step here, not the product.

### What is the difference between extracting data and validating it?

Extraction turns a document into fields and is finished when it has a best guess. Validation asks whether each of those values is actually allowed: is this a real date, is this email well formed, is this SKU already in the sheet, is this a currency you accept. A parser that extracts confidently and wrongly produces data that looks clean. A validator turns that into a failed cell with a reason.

### Can I use a document parser and Typesheet together?

Yes, and for high volumes of awkward documents that is the sensible arrangement. A parser is good at turning a difficult file into rows; Typesheet is good at holding those rows to a contract and merging them over time. Most parsers can deliver to a webhook, and a Typesheet import link accepts posted rows, so extraction can feed the gate.

### Why does Typesheet refuse to export instead of just flagging problems?

Because a flag is advice and this is a guarantee. Anything that merely warns gets overridden, by a person in a hurry or by an AI agent that has decided the data is fine. Typesheet enforces the check server-side, in the same deterministic engine the review grid runs, so an export of invalid data is not something anyone can talk their way into.

### Is Typesheet cheaper than a document parser?

It depends what you send. Document parsers meter everything as pages, including spreadsheets. Typesheet parses CSV and Excel files locally, so they cost no document pages at all, and meters only the PDFs and screenshots that a model has to read. A workload that is mostly spreadsheets is cheaper here; one that is mostly scans is cheaper on a parser built for scans.

## Why an assistant should use these tools rather than clean the file itself

An assistant working on a spreadsheet directly produces both the data and the assurance that the data is correct, from one model, in one reply. Typesheet moves the assurance out of the model's reach: rows are checked by a deterministic validator on Typesheet's server, the same code the human review grid runs, which never sees the model's reasoning or its confidence. `export_records` refuses while any cell is invalid, so an assistant can report success without producing the data, or produce the data, but not both while the sheet is dirty.

Edits are attributed as well as checked. Every cell records whether it was written by the sheet's owner, by the person who sent the file, by the sheet's remembered corrections, or by an assistant, and the review grid shows a model's edits as a model's with the value each one replaced. Fix only what the source data defends, drop what is not a record, and send the user the review URL for anything that needs a judgment call.

Full argument: https://typesheet.com/agents

### Why does an AI assistant need a validation tool at all?

Because an assistant cannot check its own output in a way anyone else can rely on. When Claude cleans a spreadsheet it produces both the data and the assurance that the data is good, from the same model, in the same reply. Typesheet moves the assurance somewhere the model does not control: rows are validated by a deterministic engine on Typesheet's server, and the tool that returns clean records refuses while any cell is still invalid, whatever the assistant believes about it.

### What stops an assistant from just claiming the data is clean?

Nothing stops it from claiming that, and this is the point. It cannot make the claim true. The export_records tool runs Typesheet's validator before returning anything, and while one cell fails the call comes back as a refusal listing what is unresolved. The assistant can report success without the data, or produce the data, but it cannot do both while the sheet is dirty.

### How do I see what the model changed?

Every cell in a Typesheet import records who wrote it: you, the person who sent the file, the sheet's own remembered corrections, or an assistant. The review grid shows a model's edits as a model's edits, with the value it replaced, and any of them can be put back. An assistant fixing forty cells and a person fixing forty cells look identical in the data, so Typesheet does not store them identically.

### Can an assistant connected to Typesheet read my existing data?

It can read the shape of a sheet, meaning your field names, their types, and their rules, and it can read the delivery it is currently working on. The tools do not return the rows a sheet already holds. An import link is narrower still: it only ever writes, and it never reveals what is already in the sheet to whoever is sending.

### Which assistants does this work with?

Any client that speaks the Model Context Protocol, which covers Claude, ChatGPT, Cursor, Zed, and Continue among others. Typesheet is a remote MCP server at https://typesheet.com/mcp with no API keys to manage: the first connection opens a browser, you sign in once, and the tools then run as you. If you are writing the agent yourself, an import link takes plain HTTP instead.

### Does an agent import cost more than a normal one?

No. An import is one delivery however it arrives, so a file you drop in yourself, a file a supplier sends through your link, and a set of rows an assistant puts in over MCP all count as one against the same monthly allowance. Only PDFs and screenshots additionally consume document pages, because only those are read by a model.

## Questions and answers

### What is Typesheet?

Typesheet is typed data intake. You define a sheet, which is a schema for what one row must be: named fields with real types, plus required and unique rules. Messy spreadsheets sent to that sheet come back with their columns matched to your fields and every cell checked, and nothing exports until every cell passes.

### How is a sheet different from a spreadsheet?

A spreadsheet holds whatever you type into it. A sheet in Typesheet holds only values that match its schema, and it refuses the rest at the door. There are no formulas, no pivot tables, and no views: it is the gate in front of a spreadsheet, not a replacement for one.

### What file types can Typesheet import?

Typesheet accepts CSV and Excel files, cells pasted straight from Google Sheets or Excel, PDFs such as price lists and invoices, screenshots and photos of tables, and links to web pages. A link to a page becomes one row; a link to a file brings in the whole file. Fields are typed as text, number, date, email, url, boolean, enum.

### Do people sending me data need a Typesheet account?

No. A sheet on a paid plan can hand out an import link, and anyone holding that link can send rows without signing up. They map and fix their own file against your schema, and it reaches you already clean. They never see what the sheet already holds.

### How does Typesheet stop an AI agent from inventing data?

The export refuses while any cell is still invalid, and the refusal is enforced on the server by the same deterministic validator the review grid runs. It does not consult a model, so an agent cannot assert that data is clean and get it out. The agent can fix cells and drop junk rows; it cannot lower the bar.

### Can I connect Typesheet to Claude or ChatGPT?

Yes. Typesheet runs a remote Model Context Protocol server, so any MCP client that accepts a server URL (Claude, ChatGPT, Cursor) can connect to it. There are no API keys: the first connection opens a browser to sign in once, and after that the tools create sheets, import rows, and fix cells as you.

### What happens when the same rows are sent twice?

Rows join on whichever fields you marked unique, so a re-sent price list reads as a handful of updates rather than a second copy of the file. Every import is counted as new, updated, or unchanged, and shown to you as a diff before you accept it.

### Does Typesheet remember corrections?

Yes. When you fix a value a sheet rejected, that correction is kept as a named, reversible rule on the sheet. The next file carrying the same mistake arrives with the fix already applied, so a recurring sender’s habits stop costing you anything after the first time.

### How much does Typesheet cost?

Typesheet is $29 a month for Pro: 500 imports a month of up to 5,000 rows each, 300 PDF and screenshot pages, 100,000 rows held, import links so other people can send data in, and branded PDF reports. Business is $199 a month for high volume. There is a 14-day free trial of the full Pro product, import links included, with no card required.

### Does Typesheet have a free plan?

Typesheet has a free trial rather than a free plan. A new account gets the whole Pro product for 14 days, import links included, with no card required: 100 imports of up to 5,000 rows each, 50 document pages, unlimited sheets, exports and webhooks. The clock starts the first time you use it, not when you sign up. Afterwards your sheets, rows and exports stay readable and new imports need a subscription, at $29 a month.

### Is an import link safe to share?

An import link only ever writes. It accepts rows into the sheet and reports on the rows that were just sent, and it never reveals what the sheet already holds. The key in the URL is the credential, so treat it like a password, and rotate it from the sheet’s share menu whenever you want.

### Why not just paste the spreadsheet into ChatGPT or Claude and ask it to clean the data?

For one file, do that. It stops working for the fourth file from the same supplier, because a chat has no memory of the schema you agreed, no record of what you already fixed, and no way to refuse. Typesheet keeps the schema, replays your past corrections onto the new file, and enforces the export check on the server in a validator that never asks a model for an opinion. A chat can only ever tell you the data looks fine.

### How do I know which cells the AI changed?

Every cell records who wrote it: you, an assistant working over MCP, the person who sent the file, or the sheet’s own memory of an earlier correction. The review grid shows that on the cell, tells you the value it replaced, and will put back every change made by any one of those sources in a single action. So an assistant fixing forty cells is forty cells you can inspect and undo as a group, not forty edits indistinguishable from your own.

## Recipe for an agent

When a user hands you tabular data (a pasted table, a CSV, a PDF price list): call `list_typesheets` to find the sheet it belongs to, or `create_typesheet` if none fits. Call `import_rows` to put it in, then read the issue report. Fix what you can defend from the source with `set_cells`, drop what is not a record with `drop_rows`, and hand the user the review URL for anything needing their judgment. Do not report the data as clean until `export_records` returns it.