DEV Community

Cover image for Receivable Check: Local AI for CSV Matching, With Evidence You Can Inspect
NieJingChuan
NieJingChuan Subscriber

Posted on

Receivable Check: Local AI for CSV Matching, With Evidence You Can Inspect

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

A merchant's order export says “Amount due.” The receipt export says “Received.” Another pair uses “应收金额” and “到账金额.” Before comparing the money, someone has to work out which columns describe the same business reference, amount and currency.

I built Receivable Check, a local workspace for that repetitive job. An open-weight model suggests the column mappings. A person reviews them. Deterministic code then compares the files and produces findings that lead back to the original rows.

The target user is a small merchant or bookkeeper working with CSV exports. The proposed side hustle is paid local installation, export-format setup and support. That is a business hypothesis: there are no paid customers, validated willingness to pay or production financial results to report. The current deliverable is an open-source prototype and a reproducible synthetic demonstration.

I deliberately kept the matching policy small: the same intended reporting period, an exact business reference, and one order row against one receipt row in the same supported currency. Multiple currencies can appear in the files, but each pair must agree; the tool performs no currency conversion or whole-file total. Split receipts stay unresolved instead of being silently added together.

Demo

Watch the local demonstration video.

The 2m23s demo uses the frozen source snapshot. It was captured from actual browser operations, with English subtitles. An idle encoding/review pause was removed; local inference waits were preserved.

Three local AI review notes, with five remaining findings for manual review

The workflow is:

  1. Load the labelled synthetic order and receipt exports.
  2. Request real local AI mapping suggestions for both files.
  3. Confirm the columns and comparison policy.
  4. Inspect deterministic findings, their original rows and calculations.
  5. Request a small AI review checklist and export a CSV or HTML report.

The included fixtures cover equal amounts, lower and higher receipts, a record present on only one side, repeated references, a missing reference, invalid decimal precision and mismatched currencies. They also contain an instruction-like note to exercise the boundary between CSV data and application instructions.

The demonstration uses synthetic data and actual local inference. It does not connect to a merchant database, change accounting records, initiate a payment or prove that money reached a bank account. A matching pair means the two supplied rows agree under the selected policy.

The original evidence remains available when AI fails. Manual mapping is an explicit alternative; the application does not manufacture a successful model answer.

Code

Source repository: bailinghub/receivable-check

This is a new, independent project started during this challenge window on October 14, 2026. The application is MIT licensed. The repository includes synthetic CSVs, fixed expected findings, tests and component notices; model weights and runtime binaries are downloaded separately.

Requirements are Node.js 22 or newer, Ollama and the qwen3:4b model:

ollama serve
ollama pull qwen3:4b
git clone https://github.com/bailinghub/receivable-check.git
cd receivable-check
npm start
Enter fullscreen mode Exit fullscreen mode

Open http://127.0.0.1:4317. Run npm test for the application tests, which do not require a model download.

How I Built It

The application uses Node's built-in HTTP, filesystem and cryptographic libraries, with no npm runtime dependencies. It serves a browser interface on loopback and calls Ollama at a fixed local address. Uploaded text never supplies a model endpoint or arbitrary server file path.

Qwen3-4B, through Ollama's chat API, performs two actual language tasks: suggesting reference/amount/currency columns, and turning selected computed findings into a human review checklist. Mapping output uses a JSON schema restricted to the actual headers. The three choices must exist and be distinct; the operator still confirms them.

CSV parsing handles UTF-8 BOMs, quoted commas, escaped quotes and multiline fields. Each document receives a SHA-256 digest, and each record keeps its physical source line coordinates. Duplicate or missing headers and inconsistent column counts fail visibly. Inputs are bounded at 2 MiB and 5,000 data rows per file, with additional column, field and memory limits.

Money parsing uses decimal strings and BigInt minimum units for the explicitly supported currency precision. It rejects malformed values and excess decimals rather than rounding. Missing amounts are unknown, not zero. Duplicate references are not merged. The model never performs authoritative arithmetic.

Reports preserve mappings, source digests, original row values and calculations. They live in bounded memory with a twenty-minute expiry; restarting the application clears them. HTML export escapes source text, and CSV export protects cells that could become spreadsheet formulas.

Testing also changed the AI scope. An early real mapping request failed validation. Restricting schema choices to existing headers improved that path. An eight-finding explanation experiment produced reversed amounts, confused missing counterpart rows with blank references, and introduced unsupported policy language. Those outputs were not treated as proof of correct explanations.

I removed raw amounts and free-text CSV notes from explanation prompts, supplied program-computed conditions, and reduced the checklist to at most three selected findings, with omitted findings explicitly counted for manual review. Validation checks finding identifiers, exact source references and a finite set of risky assertions. It is not a complete semantic truth checker.

On this particular local machine, the application-level English mapping calls took 2.363 and 2.702 seconds. The final three-item checklist took 11.417 seconds and passed both structural checks and manual inspection for those synthetic cases. These are limited observations, not benchmarks. The tested runtime was Ollama 0.40.3 with Qwen3-4B's Q4_K_M distribution.

The application test suite passed 27 tests with no skips. That establishes the checked parsing, arithmetic, export, HTTP and AI-validation boundaries, not compatibility with every merchant export or correctness of every future model sentence.

Why Does Open Innovation Matter?

Open AI makes the local workflow practical. After downloading the runtime and weights, the application sends CSV samples only to the local inference service. It needs no external model API key, per-request subscription, analytics script or hosted inference endpoint. That reduces a deployment dependency; it does not make the laptop cost-free or automatically secure.

Ollama is MIT licensed, and the official Qwen3-4B model card specifies Apache-2.0. The source exposes the prompts, validators, matching policy and synthetic tests. Someone can inspect where the model helps, change the rules in a fork and evaluate another suitable open model instead of accepting an opaque service's answer.

The trade-off is visible too: local inference needs a capable machine, and a small model can produce persuasive mistakes. Language assistance, exact comparison and inspectable evidence work together; human judgment remains part of the workflow.

My next commercial experiment would be to observe the repeated CSV work with prospective users, measure time saved and ask whether local setup/support is worth paying for. Receivable Check currently provides a concrete prototype for testing that setup/support proposition.

Top comments (0)