Hey everyone,

If anyone here works in local primary transport, fleet management, or cross-border logistics, you know the absolute nightmare that is driver document collection. Getting physical PODs, weighbridge slips from the ports, or handwritten diesel logbooks back to the depot in one piece - unstained and readable - is a massive operational bottleneck.

I’ve been experimenting with building a localized automation pipeline using n8n (an open-source workflow tool) and a vision model (Pixtral-Large) to let drivers just snap a quick WhatsApp/Telegram photo of the document while on the road, instantly transforming it into structured backend data.

Since local logistics paperwork is uniquely messy (and often handwritten), standard out-of-the-box OCR completely fails. I wanted to share the technical architecture I put together to solve this, to see if anyone else has tackled this differently or has feedback.

🛠️ The Architecture: A "Two-Pass" Approach

Sending a random logistics document to a Vision LLM and asking it to extract "everything" yields terrible accuracy because a fuel receipt looks completely different from a port weighbridge slip. I split the workflow into two separate phases:

1. Pass 1 (Classification): The image is sent to the model with one sole instruction: Classify this document type. It maps it strictly into one of four buckets: a POD/Delivery Note, a Loading Weighbridge slip (e.g., source quarries/mines), an Offloading Weighbridge slip (e.g., port terminals like Saldanha or Durban), or a Diesel logbook page.
2. Pass 2 (Targeted Extraction): A conditional switch routes the image to a highly specific prompt designed only for that document type. If it's a weighbridge slip, it targets Gross/Tare/Nett tonnage. If it’s a diesel log, it targets odometer readings and liters.

🔍 Handling Messy local Data Upstream

Because drivers write down names differently or use random abbreviations, I built a Fuzzy Matching Engine on the backend.

The system fetches master reference data (registered drivers, specific clients, known delivery locations). It runs a Levenshtein distance algorithm to auto-correct raw text variations. For instance, if a driver scribbles a variation of a supplier or location name, the engine automatically matches it to the clean, official canonical database entry.

👥 Human-in-the-Loop Validation

Because financial and billing data shouldn't be blindly trusted to AI, nothing hits the production tables automatically.

Instead, the extracted text and match results are staged in a pending table, and a structured summary is sent directly to an operations manager via chat with interactive [✅ Approve] or [❌ Reject] buttons. The manager sees exactly what the AI read, any auto-corrections made, and a warning flag (⚠️) for any low-confidence text before it's pushed to the database.

For those running or developing for local fleet operations, how are you currently minimizing the friction between on-the-road drivers and back-office billing? Are you moving towards custom driver apps, or sticking to chat-based ingestion?

Would love to hear your thoughts or answers on how you've handled the handwritten document problem!

Hey everyone,

If you deal with fleet management, primary logistics, or freight coordination, you already know the worst part of the job: document collection. Drivers are on the road trying to manage Proof of Deliveries (PODs), supplier/port weighbridge slips, and fuel receipts. They get lost, stained, or sit in the cab for weeks before being dropped off at the depot, completely stalling the billing and reconciliation cycle.

We recently built an automated Document Ingestion Pipeline using n8n (an open-source workflow automation tool) and Mistral’s Pixtral-Large vision model to let drivers simply snap a photo of their documents on the road and submit them instantly.

Here is exactly how the architecture works and why we built it this way to handle the messy reality of supply chain paperwork (including handwritten logs).

🛠️ The Architecture: A "Two-Pass" OCR Strategy

One of the biggest mistakes people make when building AI document extractors is sending a random image to an LLM with a massive prompt asking it to find "everything." It fails constantly because a fuel receipt looks completely different from a port weighbridge slip.

To hit production-grade accuracy, we built a Two-Pass OCR system:

1. The Ingestion Layer: The driver snaps a picture and sends it via an instant messaging channel (we started with Telegram, but it easily swaps to WhatsApp).
2. Pass 1 - AI Classification: The system sends the raw image to the Vision LLM with one job: What am I looking at? It classifies the document into one of four rigid buckets:
   • POD / Delivery Note (DKL notes, quarry loadcons, trip sheets)
   • Loading Weighbridge Slip (Mine/quarry source slips with Gross/Tare/Nett)
   • Offloading Weighbridge Slip (Port/plant destination slips)
   • Diesel Log / Fuel Receipt (Handwritten fleet logbooks or fuel station receipts)
3. The Router & Pass 2 - Targeted Extraction: Once the document type is identified, an n8n conditional switch routes the image to a highly specific, schema-enforced prompt written solely for that document type. If it's a weighbridge slip, it strictly extracts metrics like tons, supplier, and order numbers. If it’s a diesel log, it pulls odometer readings and liters.

🔍 Solving the "Messy Data" Problem Upstream

We knew we would never get 100% data extraction accuracy straight out of the box. Many delivery notes are scribbled by hand, and drivers use different abbreviations for the same locations or products.

To solve this, we engineered two specific safeguards into the pipeline:

• The Fuzzy Matching Engine: The workflow connects to our database backend (Convex) and pulls canonical master data (hundreds of registered drivers, products, clients, and trucks). We use a Levenshtein distance algorithm to fuzzy-match the messy text pulled by the AI. If a driver writes "Blacrock" or "Zink", the engine automatically maps it to the official master data ("Blackrock" or "Zinc").
• Truck Reg ↔ Fleet Number Lookup: If the AI can't read a faded fleet number on a cab door, but it can read the license plate on the document, the workflow automatically cross-references the registration against the asset database to resolve the correct fleet number.

👥 Human-in-the-Loop Validation (The Guardrail)

We don't trust AI blindly with financial and billing data. Nothing hits the main ERP/consignment table automatically.

Instead, the cleaned data is staged in a pendingDocuments table, and a structured summary message is pushed back to the logistics manager via Telegram/WhatsApp with two simple interactive inline buttons: [✅ Approve] or [❌ Reject].

The manager sees exactly what the AI read, what it auto-corrected, and any low-confidence fields flagged with a warning sign (⚠️). One tap approves the data into the production database; a rejection keeps it flagged for manual audit.

📈 The Bottom Line Impact

• Real-time Billing: Instead of waiting days or weeks for physical papers to return to the office, the back-office team gets structural data and digital copies within minutes of an offload.
• Frictionless for Drivers: Drivers don't need to log into a clunky enterprise app. They use apps they already know (WhatsApp/Telegram).
• Scalability: It eliminates hours of mind-numbing manual data entry for the administrative staff.

Our next milestone is optimizing upstream data collection to phase out handwritten logs entirely, but using an orchestration tool like n8n combined with Vision LLMs has completely changed how we handle field paperwork.

Would love to hear how your operations are tackling document intake, or what workflows you're using to keep drivers from losing PODs!

Hey everyone, I wanted to share a workflow architecture I recently configured for a client. This is how we solved a very common enterprise bottleneck:

Bridging the gap between unstructured vendor documents and a legacy ERP system, without relying purely on black-box AI.

​If you are dealing with document extraction (Different Document Types) and legacy integrations, hopefully, this provides some helpful context!

​The Business Problem

​The client receives high volumes of complex Purchase Orders (POs) from major vendors. Historically, a user had to open a PDF, read it, and manually key the line items and header info into their ERP (SysPro) to generate a Sales Order. It was incredibly slow, tedious, and prone to human error.

​The Objective

​The goal was not just to "add AI," but to build a highly accurate, measurable automation pipeline. We needed to eliminate the manual data entry while acknowledging that OCR/AI will never be 100% perfect. The business ultimately achieves a faster order-to-cash cycle, massive reductions in manual workload, and near-zero data entry errors - all while keeping humans strictly in control of the final data quality.

​Here is a breakdown of how the workflow is configured.

​1. The Frontend (Upload & Human-in-the-Loop)

​We built a custom frontend using Google AI Studio. The user experience is simple but crucial for data integrity.

​The user uploads the vendor PO PDF directly into the frontend.

​Once the background extraction is complete, n8n sends a success webhook back to the frontend.

​A pop-up UI is generated containing the extracted PO execution data (headers and line items).

​The Human-in-the-Loop: Users can review the data and explicitly Approve, Edit, or Flag individual components. This allows the AI to handle the stable 80% of the work, while the human easily manages the messy 20% before it ever touches a database.

​2. The Orchestration (n8n & Mistral OCR)

​n8n acts as the central nervous system for the entire process.

​The primary workflow takes the payload from the frontend and passes it through Mistral OCR to extract the highly complex, varied line items.

​n8n handles the logic, formatting, and routing of this data back to the frontend for that validation step mentioned above.

​3. State Management (Convex Database)

​Once a user clicks "Submit to Staging" on the frontend, the validated data is pushed to our Convex backend.

​Convex is brilliant here because we aren't just dumping data into a single bucket.

​We configured specific tables that act as state machines for the data journey. There are dedicated tables handling specific data states (e.g., ingested, validated, flagged for review).

​When data hits the "staging" state in Convex, it automatically kicks off the secondary n8n workflow.

​4. The Enterprise Handoff (SharePoint & SQL)

​Integrating directly into a legacy ERP via API can be a nightmare of rate limits and locked databases. We bypassed that entirely with a clean asynchronous handoff.

​The secondary n8n workflow takes the validated data from Convex and transforms it into a formatted SQL script.

​n8n then posts this SQL file directly into a secure SharePoint folder.

​The client’s internal environment runs a cron job to pick up this SQL script, load it into their own SQL staging database for a final safety check, and seamlessly post it into SysPro to generate the Sales Order.

​By combining n8n for orchestration, Convex for state management, and a strict human-in-the-loop frontend, we avoided building an "expensive mirror" of bad data. It’s a very robust way to handle AI document processing in traditional enterprise environments.

​Happy to answer any questions about the specific configurations or how we set up the n8n webhooks!