7 Ways to Use AI to Stop Retyping What You Already Have

Using AI to stop retyping what you already have is the least glamorous thing on this site and probably the closest to your actual week. Not writing. Not ideas. Just the address that's in the email and needs to be in the invoice, the fourteen line items on the paper docket that need to be in the spreadsheet, the same six answers you've typed into nine different supplier forms this year. The information exists. You own it. And you're typing it again.

Here's the part most advice misses. The cost isn't the keystrokes, it's the translation, which is why learning to type faster never helped. One system calls it "Company," the other calls it "Account Name." One wants a single Full Name field, the other wants first and last separately. One writes dates as 09/28, the other refuses anything but 2026-09-28. Every transfer is a small act of interpretation, which is exactly the work a language model does well and a macro does badly. Asana's survey of 2,007 U.S. knowledge workers put duplicated work and work no longer relevant at 308 hours a year per person. Self-reported, so treat it as a shape rather than a measurement, but nobody who has kept two systems in sync by hand will find it surprising.

Seven ideas below, and not one of them asks a model to invent a single fact. Each ends with something you can do this afternoon.

1. Turn the Paper on Your Desk Into Rows Instead of Text

Scanning paper into text has been possible for twenty years and it never solved this problem. You'd feed in a receipt and get back a paragraph: store name, some prices, the tax, all in reading order, all of it still needing to be picked apart and typed into the right boxes. The scan saved nothing, because the retyping was the job.

What changed is that you can ask for the fields instead of the text. Hand over a photo and say what you want back: vendor, date, subtotal, tax, total, category, in that order, as one row. You get a row. Not prose about a row. The same move works on a handwritten delivery docket, a business card, a paper timesheet, an insurance declaration page, a parts list a supplier faxed you in 2019 and still faxes you now.

Your existing software may already do the narrow version of this for free. Excel ships a feature called Insert Data from Picture that turns a photographed table straight into cells, and Google Drive converts an uploaded image or PDF into an editable document with no setup at all. Try those first on anything already laid out as a clean table. Reach for a chat model when the source is messy, or when the fields you need aren't the fields on the page.

Start today: Photograph one receipt from the pile. Ask for a single comma-separated row using your own column names in your own order, and nothing else. No explanation, no heading, no summary. Paste it straight into the sheet.

2. Let the Destination Decide the Shape

Priya manages the office for a dental supply distributor and spends Tuesday mornings turning supplier emails into purchase orders. She'd been describing what she wanted every time, in slightly different words, and getting output that was close but never quite droppable into the system. Then she did something small. She exported one existing purchase order, deleted the data, kept the header row, and saved it in a note.

Now that header row goes at the top of every request. Here are the exact columns, in this order, with this date format, and here's the supplier email. Fill it in. The output arrives already shaped like the destination, and checking it takes seconds instead of a squint.

Most people describe a transfer from the source end, which is backwards. The source can be anything. The destination is fussy, specific, and unchanging, so it's the thing worth writing down once. Your destination's empty header row is a specification you didn't have to write.

Start today: Pick the system you type into most. Export one record, delete the values, keep the headers. Save that line somewhere you can paste from. Add a note next to any column that only accepts certain values, because that's the other half of the spec.

3. Get the Numbers Out of a Screen With No Export Button

Some data has no file. A supplier portal that shows you a statement and offers nothing but Print. A dashboard in an old system with no download icon anywhere. A PDF bank statement where selecting the text gives you a scrambled mess. This is where the worst retyping lives, because there's no export to find and no menu to hunt through.

Screenshot the table and ask for the rows back. It works well, and it fails in one specific way worth knowing about: column boundaries. When two columns sit close together, values can get read into the wrong one, and the output looks perfectly clean while being wrong. So always ask for a column total alongside the rows and compare it to the total printed on screen. If they match, the columns held. If they don't, you've caught it in ten seconds rather than in a month.

If the same locked screen produces the same locked report every month, that's a job to move out of your hands and into a spreadsheet workflow rather than something to do again in thirty days.

Start today: Find one screen you've retyped from before. Screenshot the table, ask for it as rows plus a column total, and check that total against what the screen says. Now you know whether this route is trustworthy for that particular layout.

4. Hand Off the Transfer You Do Every Monday

Items one through three are moves you make once. This is the one you stop making, and only certain jobs qualify: the transfer that happens on a schedule, in the same direction, between the same two systems, with the same fields every time. The Monday export into the tracker. The month-end figures into the report. Anything you could describe to a new hire in four sentences.

Those four sentences are the entire specification, and the fourth is the one people leave out. A row with no email address, a date in a format nobody predicted, a name with an apostrophe in it. Decide now: skip it and report it, or stop everything and ask. Either answer is fine. Having no answer is what turns a useful transfer into a mess you unpick later.

Write the four sentences down and the job is describable, which means it's handable. That's the idea behind letting one system fill the other one for you: you keep the judgment about what the fields mean, and the machine keeps the part where it does the same thing forty times without getting bored on row thirty-one.

Start today: Take the transfer you did most recently and write the four sentences. Source, destination, field mapping, what happens on a bad row. If you can't finish the fourth sentence, that's the thing worth thinking about before anything gets automated.

5. Find the Field That Identifies a Record Before You Move Anything

Here's the mistake that turns a time-saver into a weekend of cleanup. You move two hundred rows into a system that already holds some of them, and instead of updating what's there, you create second copies. Now you have two of everything, some new, some old, and no way to tell at a glance which one anybody has been editing.

The cause is always the same: no agreed answer to "what makes this the same record." Airtable's own CSV import documentation puts it plainly, that merging into existing records means choosing a field with a unique value such as an ID or an email address. Most tools ask the same question at import time, and most people click past it.

Use a model for the part you can't eyeball: whether any field in your data is unique enough to trust. Paste in fifty real rows and ask which column, or which combination of columns, identifies a row without collisions. You'll learn that two people at the same company share an email, that six customers have the same name, that your reference numbers restart every year. Sometimes the answer is that no stable identifier exists yet, and creating one is the real first job.

Start today: Export fifty rows from the system you import into. Ask which single field or pair of fields uniquely identifies a record in that sample, and to list every collision it finds. Whatever survives is your merge key, and you use the same one every time from now on.

6. Build One Answer Bank So the Same Questionnaire Stops Being New Work

Marcus runs a four-person web development shop and figures he fills in twenty of these a year: vendor onboarding packs, insurance renewals, security questionnaires from enterprise clients, supplier registration portals. Different forms, different wording, the same underlying facts. Company registration number. Years trading. Which countries data is stored in. Whether there's a written incident response policy.

He keeps one document now. Not a template, an answer bank: every standing fact and every answer he's already written carefully, each with the date he last confirmed it. When a new form arrives he hands over both, the form and the bank, and asks one specific question. Which of my existing answers covers each item on this form, quoted as written, and which items have nothing in the bank that fits.

That second list is the only real work, and it's usually three questions long instead of forty. Same instinct as using AI to select from what you already wrote rather than to generate, pointed at forms instead of a content library. And the bank compounds: every careful new answer goes in, dated, so next year's version of the same form is shorter still.

Start today: Open the last long form you filled in and copy your answers into a fresh document, one per line, each with today's date. That's the first version of the bank. It'll pay for itself on the next form, and you didn't need AI to build it.

7. Let the Two Systems Meet in a File You Can Read

Once this starts working there's a temptation to want the transfer to happen invisibly: click a button, rows appear over there, nobody looks in between. Resist that for a while. Keep the middle file.

Export from the source, reshape into a file, import into the destination. That readable file in the middle does three jobs. It's your undo, because you can see exactly what went in. It's your record, because in six months when a number is disputed you have the thing you sent rather than a memory of sending it. And it's your test, because you can eyeball twenty rows before committing two hundred.

It also lets you use the import your destination already ships, which is nearly always the most reliable way in. Almost every business tool has a bulk import buried in a menu, with a documented template and required fields, and almost nobody uses it because the template looks like homework. Getting your data into that template is the only part that needed a model. Plenty of grids take a straight paste from a spreadsheet with no import step at all. When the whole loop turns into something you run every week, it belongs in a workflow that handles the keying for you rather than in your calendar.

Start today: Next transfer you do, save the middle file with the date in its name. Do that four times and you have a history of what you sent where, which is worth more than it sounds the first time somebody questions a figure.

Pick One

Don't try all seven. If nothing on the list jumped out, take number two, the empty header row. It takes twenty minutes, it makes every other idea here work better, and it's the one people mention a year later as the thing that changed their week.

The thread running through all of this: you're not short of information, you're short of a way to move it without your hands. Sunday we report what changed in AI, Wednesday we take one workflow apart and rebuild it, and Monday is for ideas like these. When a transfer stops being occasional and becomes a chore with a day of the week attached to it, the workflow directory shows what other people handed off instead of doing again.

Frequently Asked Questions

• Isn't this just copy and paste with extra steps?+
  Copying is the cheap part. The expensive part is reshaping: splitting one name field into two, turning a date into the format the other system will accept, deciding which of eleven columns the receiving form even has a home for. That is the work these ideas remove. If a job is genuinely one value moved from one box to one identical box, keep doing it by hand, because describing it will take longer than doing it.
• Do I need an API or an integration to move data between two tools?+
  Usually no. Most of what people retype every week can travel on an export and an import, which nearly every business tool already has buried in a menu. An API is worth it when the transfer has to happen the moment something changes rather than once a week. Start with the file route, because you can read a file, check it, and keep it. If the same route runs every week, that's the point at which handing the whole transfer over costs less than continuing to run it.
• How do I know the transfer didn't quietly get something wrong?+
  Check three things before you trust a batch: the row count in equals the row count out, any column of numbers adds up to the same total on both sides, and five rows picked at random match their source. That catches the failures that matter, which are the silent ones like a shifted column or a date read as the wrong month. The wider habit of catching quiet mistakes is covered in the edition on what to do after it gets something wrong.
• What if the receipts and forms contain client or personal information?+
  Then decide where the data goes before you decide which tool is clever. Strip the fields the destination doesn't need before anything leaves your machine, and for material you cannot send out at all, a small model running locally on the laptop you already own will read a table well enough for this kind of work. The edition on working without a subscription covers how to set that up. Fewer fields moved is also less to check.