Now It Reads Excel Too, and That Breaks the Old Import Rulebook

Every custom import I've built in NetSuite breaks the same way. Someone moves a column, renames a header, or pastes the data one row lower, and the script that ran clean for a year stops finding anything.

That's the part of this work that never makes it into the proposal.

Two months ago I wrote about replacing a $12,000/year document automation SuiteApp with a build you pay for once. Claude handles the extraction, native NetSuite does the rest, and the AI usage runs around $7.50 a month at real volume.

Quick update: it's live. Running in production for a customer, turning real documents into real records.

And along the way it picked up something I didn't originally scope.

Now it reads Excel, not just PDFs

The first version targeted scanned PDFs. Inbound purchase orders, sales orders, estimates. That same customer needed Excel files moving into NetSuite through the same door.

So we pointed the extraction step at spreadsheets. Same intake record. Same side by side review screen. Same NetSuite scripting on the back end. The only thing that changed was the file type arriving at the front.

Why that matters more than it sounds

Here's where it stops being a checkbox feature.

The old way of getting a spreadsheet into NetSuite is rigid on purpose. You build a saved CSV import map, or you write a script that reads column C for the item and column F for the quantity. It works right up until the file doesn't match. Wrong header. An extra column. Data starting on row 4 instead of row 2. A yes/no field typed as "Yes" instead of "T". Any of those and the import fails, or worse, imports the wrong thing quietly.

Anyone who's supported a recurring NetSuite import knows the babysitting that comes with it.

Claude doesn't read column C. It reads the data.

You describe what you're after. A customer. An item. A quantity. A date. It pulls those from the sheet even when the layout drifts. Columns in a different order. A summary row jammed at the top. A header worded slightly differently this month than last. The rigid coordinate mapping falls away, and what's left is a plain description of the data you want instead of the exact cell it has to live in.

Same structure I built for PDFs. Now applied to spreadsheets nobody formatted for me.

The hidden tax on custom imports

Custom import work has always carried a cost people forget to budget for. Not the initial build. The upkeep.

Every time a vendor tweaks their export or a customer sends a slightly different template, someone reworks the mapping or patches the script. That maintenance never ends, because the inputs never stop moving.

When the extraction tolerates variation, most of that tax disappears. One pipeline handles PDFs and spreadsheets. A new file shape doesn't automatically mean new development. You describe intent once instead of remapping coordinates forever.

It's the same reason the original build undercuts a subscription SuiteApp. You pay for the judgment up front, then run it for pennies, instead of renting a rigid tool that bills you every month whether your files cooperate or not.

The honest limits

Flexible isn't magic. You still need data that means what it says, and low confidence cases still route to a person to review. The machine doesn't stop needing a second set of eyes.

The point is smaller and more useful than that. The thing you build stops breaking every time the input shifts an inch.

If you're running recurring imports into NetSuite and quietly spending real hours keeping the templates alive, that's the problem worth looking at. I'm happy to show you the live version reading a real file.