SupplierSignal AI: An Open-Source Supplier Verification Tool

Small Sellers' Supplier Reconciliation Problem Finally Gets an Open-Source Solution

Anyone in e-commerce has probably been through this: a supplier promises in chat, "We'll ship 500 units this week at 12 yuan each." Then the invoice arrives saying 480 units at 12.5 yuan each, and when the goods are actually counted at the warehouse, it turns out to be 475 units. Three records, three formats, three sources — comparing them line by line by hand is time-consuming and easy to miss details.

The team Code Killers on DEV Community open-sourced SupplierSignal AI during Hacktoberfest, and it targets exactly this pain point. It's a mobile-friendly, local-first web app that uses the open-weight Gemma model to extract structured information from procurement records, then automatically cross-checks three sets of data — "supplier promises, invoices, and actual receipts" — and flags potential discrepancies.

The project is already public on GitHub (abu-124/SupplierSignal-AI), with team members including Sayyad Abu Basha (lead), Veeru Naidu, and NVS Manikanta.

What Problem Does It Actually Solve?

Small sellers often lack a unified system for procurement. Supplier promises are scattered across WeChat, WhatsApp, or email; invoices are PDFs or paper scans; receiving records might be handwritten notes or Excel files. These three sets of information are independent, and during manual reconciliation, small discrepancies in product specs, prices, and quantities are easily overlooked. Over time, these add up to real financial losses and can even lead to supplier disputes.

SupplierSignal AI's approach isn't to replace human judgment, but to automate the comparison step — pulling out suspicious points and handing them to the seller for decision-making.

local-first is a software architecture orientation whose core premise is: user data is stored primarily on the user's own device, core app functionality works offline, and cloud sync is merely an optional enhancement rather than a prerequisite. This concept was systematically proposed by the Ink & Switch lab in their 2019 paper of the same name, targeting the SaaS-era habit of "data being uploaded to vendor servers by default."

In practice, local-first usually means three things: data persists as local files or in a local database; inference or computation happens on-device as much as possible; and the network is used only for optional collaboration and backup. The benefits include controllable privacy, no subscription or usage-based billing pressure, offline availability, and user data sovereignty. The trade-offs are certain local hardware requirements, and more complex multi-device sync and conflict merging. SupplierSignal AI's choice to run Gemma locally via Ollama is a concrete implementation of this philosophy.

Core Features Breakdown

According to the project description, the tool's capabilities center on four areas:

• Information extraction: Using Gemma, an open-weight AI model, to convert unstructured procurement records into structured data. This step is the foundation of the entire workflow — extraction accuracy directly determines the credibility of subsequent comparisons.
• Three-way comparison: Cross-verifying supplier promises, invoice details, and actual receipt records together.
• Discrepancy flagging: Not just finding "mismatches," but also flagging missing information and uncertain matches — the latter is especially important because AI extraction itself has confidence issues. Distinguishing "uncertain" from "definitely wrong" prevents misleading users.
• Report generation: Outputting discrepancy reports to help sellers investigate further or communicate with suppliers.

There's another design orientation worth mentioning separately: local-first. Sensitive procurement and pricing data stays on devices the seller controls, never going to the cloud. For small merchants, supply chain data is often their core business secret, so this choice is a plus in terms of privacy and trust.

open-weight models refer to large models whose parameters are publicly released, allowing download and local execution — as opposed to black-box services that only offer APIs. Gemma is a series of open-weight models released by Google in 2024, with parameter sizes ranging from 2B to 27B, covering text understanding and generation tasks, built on the same technical lineage as Gemini.

Open weights aren't the same as fully open source: in most cases, licensing terms impose conditions on commercial use, redistribution, or derivative training, and users need to check the specific terms. But compared to closed-source APIs, the key advantages are offline deployment, fine-tuning capability, fixed inference costs, and the fact that input data doesn't have to leave the local machine. This is why open-weight models are often the more suitable choice when dealing with sensitive information like procurement prices and supplier lists.

Tech Stack and Workflow

The tool's technical composition is fairly restrained:

• Python handles backend logic
• Gemma takes on information extraction tasks
• Ollama runs the model locally, which is the prerequisite for making local-first work
• Web technologies build the interface and user flow

The usage flow has five steps: create a procurement case → enter supplier agreements or messages → fill in invoice information → add actually received goods → analyze and view reports. This linear flow lowers the barrier to entry — sellers don't need to understand the model's underlying principles.

Worth mentioning is the Ollama + Gemma combination. Compared to calling cloud-based LLM APIs, local execution has certain hardware requirements but eliminates data transfer concerns and avoids usage-based billing pressure. For small sellers with infrequent procurement, this trade-off is reasonable.

Ollama is an open-source tool for running large language models locally. It packages model downloading, quantization, loading, and inference serving into simple command-line and HTTP interfaces — users can spin up a model with a single ollama run gemma, without handling PyTorch, CUDA, VRAM allocation, or other low-level details themselves. It also exposes an OpenAI-compatible API, making it easy for Python backends to call directly.

For applications like SupplierSignal AI, Ollama's value lies in turning "local inference" from an engineering challenge into a single line of configuration: developers don't need to set up a separate service for model deployment, and sellers don't need to understand quantization bits or context lengths. The trade-off is that local inference speed and available model sizes are limited by device memory and compute — typically requiring 8GB+ of VRAM or unified memory for smooth operation of medium-sized models.

The Team's Self-Reported Takeaways and Limitations

In their project description, Code Killers candidly state this is an evolving prototype, not a mature product. What they learned from building it includes: how to organize record structures, how to compare extracted information, and how to present discrepancies as a useful report.

The team explicitly lists future improvement directions: extraction accuracy, evidence traceability, and review workflow. These three points correspond exactly to where such tools are most likely to be questioned — what happens if AI extraction is wrong? Can you trace back to the original source? Is manual review smooth?

Frankly, writing "limitations" into the project introduction actually inspires more trust than simply touting features.

Where the Real Barrier Lies for Such Tools

From a technical selection standpoint, SupplierSignal AI's architecture isn't complex. The real difficulty lies in extraction accuracy and the robustness of matching logic.

Supplier messages might say "old price" or "same as last time." Invoices might have tax rates, discounts, shipping fees, and other add-ons. Receiving records might have unit conversions (boxes vs. units). These gray areas are exactly what makes manual reconciliation most frustrating and error-prone — and also where AI extraction is most likely to fail.

The team's decision to flag "uncertain matches" separately is a pragmatic design — rather than forcing a possibly wrong judgment, it's better to honestly tell the user, "I'm not sure about this one, you should take a look."

Another area worth watching is evidence traceability. If the system flags "invoice unit price doesn't match promise," users need to be able to jump to the corresponding position in the original text to confirm with one click. This capability is currently listed as a to-be-improved item, but it's actually key to determining whether the tool can be truly trusted.

Information Extraction is a classic task in natural language processing, aiming to identify entities, attributes, and relationships from unstructured text and convert them into structured fields. Traditional approaches rely on rule templates or sequence labeling models, while LLM-based extraction typically uses "prompting + structured output," having the model directly output formats like JSON.

The weakness of this approach lies in confidence: the model might correctly extract "12 yuan," or it might incorrectly fill in "same as last time" as some historical value — and both cases look equally confident in the output format. Therefore, mature systems generally introduce confidence scoring and evidence alignment — not just giving extraction results, but also noting which sentence in the original text the result came from and how confident the model is. SupplierSignal AI's separation of "uncertain matches" from "definite errors" is a low-cost attempt along these lines.

Practical Significance for Small Sellers

The value of such tools isn't in how advanced the technology is, but in making a high-frequency, tedious, error-prone task verifiable. Procurement reconciliation isn't a one-time task — it's an action repeated every procurement cycle. Standardizing the process and making discrepancies visible can, in the long run, reduce disputes and losses that may be worth more than the time saved.

At the end of their post, the team poses a question: what other checks would be useful for sellers — for example, product size mismatches, duplicate invoices, delivery date verification? These questions themselves show they're seriously thinking about real usage scenarios, not just building a flashy demo.

The project is open-sourced under Hacktoberfest. Interested developers can go directly to the GitHub repository to view the code, file issues, or contribute improvements.

One-line Summary

Code Killers open-sources local-first tool SupplierSignal AI, using Gemma to locally compare supplier promises, invoices, and receipts for three-way discrepancies.

Paragraph Summary

SupplierSignal AI is a small-seller supplier verification tool open-sourced by the Code Killers team during Hacktoberfest, available at GitHub's abu-124/SupplierSignal-AI. It addresses the pain point of supplier promises scattered across chat logs, invoices in PDF or scanned form, and receiving records possibly handwritten or in Excel — three records in different formats that are slow and error-prone to reconcile manually line by line. The tool uses a local-first architecture with the open-weight Gemma model via Ollama for local information extraction, converting unstructured procurement records into structured data, then performing three-way cross-comparison of "supplier promises — invoice details — actual receipts" to output discrepancy reports. The team admits this is only an evolving prototype, with future focus on improving extraction accuracy, enhancing evidence traceability, and refining review workflows — while the real technical barrier lies in extracting ambiguous information and the robustness of matching logic.