OCR quote line item import: pulling rows out of a PDF

It is 4:20 on a Thursday afternoon. A proposal specialist has a nine-page scanned price list from a supplier on screen: more than two hundred rows, skewed page edges, handwritten notes in the margins. The customer expects the quote by tomorrow morning. She starts typing rows one by one, and forty minutes in she notices she has entered a unit price with the decimal in the wrong place. Now she has to re-check every line typed so far. This is where most of the time in quoting actually goes: not into thinking about the offer, but into moving rows.

This article walks through how importing quote line items from a PDF or a photo actually works, in order: what OCR really reads, which source documents produce which quality, where row detection breaks, the errors that number formats and currencies introduce, who verifies an imported line, the difference between importing a price list and importing an old quote, how the quote gets finished after the import, and how all of it fits into a two-week rollout.

Why won't the PDF on your desk just become a quote?

A PDF is a printing format, not a data format. It records which glyph sits at which coordinate on a page; it does not record that those glyphs form the third column of a table. What your eye reads as "item, quantity, unit price" is, inside the file, three separate text boxes that happen to line up. The rules between columns are usually just drawn graphics, not cell borders.

The second distinction matters more: does your file carry a text layer, or is it a photograph of paper? A price list exported from an ERP system contains real characters. The same list, printed and run through a scanner, is one flat image with no characters in it at all. The two look identical on screen and behave nothing alike. Most guides on how to put a price quote together skip this distinction and simply say "import the PDF" — which is exactly where the difficulty starts.

Third, a quote line is not a piece of text; it is a record. Item name, quantity, unit, unit price, line discount and tax rate each have to land correctly on their own. Get one wrong and the total is wrong, and the wrong total is what reaches the customer. So the import has to be designed as a field-mapping job, not as a text-grabbing job.

What can OCR read, and what defeats it?

OCR is the layer that turns shapes in an image into characters. On a clean, straight, single-typeface page, that job is reliable today. The difficulty is not in the characters but in the relationships between them: which run of words is a product name, which number is a quantity, which number is a price. That is layout analysis, and layout analysis works to the degree that the source is orderly.

The easy cases are predictable: crisply printed item names, whole numbers, column headers, currency symbols. So are the hard ones — handwritten corrections, rows under a stamp, faint grey printing, a description split across two pages, long product names that wrap because the column is too narrow. The goal of an import flow is not that OCR never errs, but that you know in advance where it will and put a check there.

It helps to treat this as a branch of the same discipline as moving data in and out of a CRM. The questions are identical: what format is the source, which field maps to which, what happens to a bad row, and can the import be rolled back?

Which source document gives which result?

Not all sources are equal. The table below summarises the four that show up most often in line-item imports — not an accuracy percentage, but which check is mandatory where.

Source	Structure	Weak point	Mandatory check
Native PDF from a system	Text layer present, columns aligned	Merged cells, subtotal rows	Row count and grand total
Scanned price list	Image, flat page	Faded print, digit confusion	Unit price on ten random rows
Photo taken on a phone	Image, skewed and shadowed	Row drift, cropped edge	Every row read end to end
PDF export of an old quote	Text layer, familiar template	Discount and tax columns	Discount, tax and currency

That order is also a preference order. When you ask the other side for a document, saying "send the PDF your system exports, no need to scan it" will improve import quality more than any software setting will. In line-item-heavy work such as a print shop, that one sentence saves half an hour on every job.

Where does row detection break?

Imports almost never fail because a letter was misread. They fail because a row boundary was drawn in the wrong place. Four cases account for most of it:

• Wrapped item names. A description spills onto a second line, and that second line is treated as its own item — a row with no quantity and no price.
• Merged cells. A header row that names a group of three items underneath it gets imported as an item.
• Subtotal rows. The subtotal at the foot of a page enters the list as the most expensive item and doubles the quote.
• Page breaks. An item cut off at the bottom of one page merges with the header of the next.

All four are obvious to the eye. The problem is that nobody is looking with their eyes at a two-hundred-row list. The fix is a small habit: after every import, look at the three most expensive rows and the three cheapest. Subtotal and empty-row errors sit almost exclusively at those two ends. When responding to an RFQ on the manufacturing side, that check is faster than reading the bill of materials and catches more.

Number formats, currency and tax: the expensive mistakes

A misread item name is embarrassing. A misread number costs money. Thousand separators and decimal marks are reversed between the English-speaking convention and much of continental Europe, and imported catalogues often mix both in one file. If the import assumes one convention and takes the other at face value, a thousandfold error settles quietly into the quote.

Currency is the second trap. The list may be in dollars while the quote is in another currency, or the list may be priced at last year's rate. Rocketly's multi-currency handling with live rates is what makes this survivable: the exchange rate at the moment the quote is created is sealed into the record, and current rates are pulled from a central bank feed. Three months later, "which rate did we use" is answered by the document, not by anyone's memory.

Third comes tax and line discounts. Price lists usually arrive net of tax; old quotes usually arrive gross. That is the most common answer to "why doesn't the total match". Marking, at field level, whether the source list is tax-inclusive is a one-time decision that prevents hundreds of later corrections. Most of what makes a quoting process that does not rely on luck is exactly this: decisions written down rather than remembered.

Who verifies an imported line?

The most misunderstood part of automated import is simple: the machine brings the rows, a person makes the decision. What comes out of the import screen is a draft, not a quote. That distinction has to exist in the process too, or "the system read it that way" becomes a gap in accountability.

In Rocketly the job is done by OCR line item import: you upload a photo of a price list or an old quote, and items, quantities and prices fill into the quote lines for you to edit before sending. The import produces a proposal; the decision to send is still yours. The same logic governs Excel line item import, where long lists arrive in one pass instead of being typed row by row.

Who verifies what should be settled by role: item names and quantities by whoever builds the quote, pricing and discount logic by a manager on anything above threshold. The Excel-to-CRM field mapping wizard shows the same mechanics on the lead side — binding a source column to a target field and quarantining bad rows works identically.

Price list or old quote? Two different workflows

Same button, different jobs. Importing a price list is catalogue work: the rows will be reused, so they deserve to be cleaned once and stored. Importing an old quote is case work: you are bringing prices given to one customer on one date back to the table.

For a price list, the right reflex is to turn the cleaned rows into a reusable set. Rocketly's template gallery exists for this: you start from a ready item set for your sector and save it as your own preset. The next quote never has to read that list a second time.

For an old quote the question is different: how much of last year's price still holds? Pulling the rows in is the easy half; deciding which of them needs repricing is the hard half. On a team that has built a proposal structure that wins, that decision already lives in the template — which items are fixed, which get repriced every time, which are optional.

How does the quote get finished after the import?

The quote is not done when the lines land. Next comes turning rows into a document: grouping, separating optional items, terms text, validity period and presentation. At this stage the speed of the import gives way to judgement.

Two things help here. First, the long imported list should not go out as-is; with package selection and partial acceptance the customer chooses between packages or approves only the lines they want, and the selection is written back to the quote. Second, quotes crossing an amount threshold or falling under a margin floor drop into the manager approval gate — they cannot be sent until approved, and the decision is written into the quote's version history. Who signed off on an imported discount is not a matter of debate three months later.

If you want to think about line configuration as a whole, the configure-price-quote model clarifies where the import sits: OCR feeds the first step, and pricing rules and document generation follow.

What does a two-week rollout look like?

Trying to stand this up in a day usually ends with the team abandoning it after the first bad quote. A staged plan works better:

• Days 1-3: Pick the three source documents you handle most often, import each once and compare the output line by line against a manually built version. The aim is learning the character of the errors, not a perfect result.
• Days 4-6: Turn those error types into a checklist: subtotal rows, wrapped descriptions, decimal marks, tax status, currency.
• Days 7-10: Save recurring item sets as presets, so frequent items are selected rather than scanned again.
• Days 11-14: Write down the approval threshold and who verifies what.

At the end of the second week, measure two numbers: time to produce a quote, and corrections issued after sending. If the second does not fall, the import got faster without getting trustworthy. Teams that already measure how a sent quote turns into a win keep both side by side; quote analytics and export pull the data as CSV into your own reporting.

Does the import write the quote text too?

No, and that boundary is worth keeping. OCR import fills the line table; the persuasive part of a quote — scope, acceptance criteria, rationale — is separate work. The real payoff of pulling lines in quickly is that the saved time goes into that text.

The sequence that works in practice is: import and verify the lines, then write the scope, then set the presentation. Teams that work in the reverse order end up placing wrong rows inside a beautiful document. That is also the precondition for producing a persuasive proposal from context: the context has to be right, or the generated text will describe wrong data very well.

If you want to try this against your own item lists, open an account and start by importing a single price list.

FAQ

Is accuracy good enough on photographed lists?

On a photo taken flat, without shadows, with the whole page in frame, the result is usually workable. Skew, glare and creased paper cause row drift. If you can choose the source, a system-generated PDF always does better.

Can I undo an import if the lines are wrong?

Every revision is stored as a snapshot, so you can return to the previous state and put two versions side by side to see the difference line by line. That is what makes trying an import risk-free.

If I have Excel, do I need OCR at all?

If you have Excel, use Excel — it is always cleaner. OCR is for when the other side sent only a PDF or a sheet of paper. Most teams use both: their own catalogue from Excel, supplier lists through OCR.

How long does a list have to be to be worth it?

Below roughly fifteen rows, typing is usually faster. The gain lives in long lists, where the time and the error rate of manual entry grow faster than the row count.