DocBatch

In progress

The second thing we are building: a whole batch of trade documents goes in, and a workbook comes back — a summary with one row per document, a detail sheet with one row per line item, in real columns. In progress, and not self-service yet.

The job it takes over

A shipment's paperwork is a set: the purchase order, the invoice, the customs declaration, the packing list. Every figure is on one of them, and none of it is in a column — so before anything at all can be checked, somebody types it into a spreadsheet.

The expensive part is not the judgement, it is the carrying: the same figures get retyped once for purchasing and again for customs. Every pass is another chance to mistype, and line two hundred does not get the attention line two got.

DocBatch takes the carrying. A batch goes in, a workbook comes out, and the time goes back into the judgement.

What one run gives back

· One workbook per document type, so the invoices and the packing lists do not land in the same table.
· Two sheets in each: a summary with one row per document, and a detail sheet with one row per line item, linked back to the summary by file name.
· The detail sheet is split into columns rather than kept as text, so it can be filtered, pivoted or summed as it arrives.
· A parse log beside them, one row per document — what was skipped is in the log rather than quietly missing from the table.
· Output file names carry the run's own timestamp, so a second run never overwrites the first.

What it can read

· A PDF that carries a text layer is parsed directly, by character coordinates rather than by recognition.
· Spreadsheet packing lists are mapped by column name rather than by a fixed layout, because in practice that layout is not fixed.
· A scan needs a text-recognition pass first, and that pass is wired up for purchase orders only. For the other types a scan is flagged and skipped — it is not quietly turned into half a table.

What it does not do

· It does not match documents to each other. The invoice, the customs declaration and the packing list each keep the fields needed to line them up, but the matching is still done by a person.
· It is in progress. There is no upload page here and no open trial: this page describes what is being built, and its status on the portal will change when it can be used.

Files and data

· Files are processed locally rather than through an upload channel on this site — this page is a description, not a form.
· When a scan needs text recognition, the image goes to a third-party recognition service. An electronic file does not leave the machine.
· Neither the documents nor the extracted results are used to train a model.

Questions

Can we try it yet?

Not yet. It is in progress and this page only describes it; when there is something to try, an entry point appears here and the status changes with it.

Which documents does it handle?

Four: purchase orders, invoices, customs declarations and packing lists. Nothing else is implemented, and we do not describe what is not implemented as if it were.

Does it handle scans?

For purchase orders, yes — a scan goes through a text-recognition pass first. For the other three it takes an electronic file: a PDF with a text layer, or a spreadsheet. A scan is flagged and skipped rather than reported as parsed.

Contact

Email is enough — there is no call to book. Everything goes through the mailbox, and we reply within 48 hours.

support@aisp.work