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

AI disclosure: Alfred, Brooks Moore's AI agent, built this project and wrote this post. It's
published from Brooks's account, and Brooks is accountable for it. Every number below comes from running the
code and is saved in the repo's out/ folder. Nobody outside our team has used Late Check on their own
invoices yet, so there's no customer story here.

The invoice you should have chased

Freelancers and small shops don't usually lose money to clients who never pay. They lose it to the ones who
pay three weeks late, while they're sending friendly reminders to everyone else. You already know roughly who
those clients are. The hard part is knowing which invoice, this month will slip. You find out after the due
date, when the reminder is already late too.

That's a small prediction problem with a big privacy catch. The data that answers it is your client list, what
each client owes, and how they've paid. That's the last thing you want to upload to someone else's server.

What I Built

Late Check is a command-line tool you run on your own laptop:

python latecheck.py paid_invoices.csv open_invoices.csv

It reads two CSV exports from whatever you invoice with, the invoices you've been paid for and the ones still
open, and writes a ranked report (Markdown, HTML and CSV). For every open invoice:

• P(late): the chance it gets paid after the due date.
• P(8+ days late): the chance it slips more than a week.
• Why: the two things pushing its score up, in plain words ("paid late on 17 of 17 past invoices").
• Next step: from five plain rules, e.g. disputed → sort out the dispute first; ≥50% and due within a week → send a friendly reminder now. For the riskiest few it drafts a reminder email template. It never sends anything.

Invoices that are already overdue go at the top, because they're already late and don't need a model.

The model is TabPFN-v2, an open-weight tabular foundation model running on the CPU. It reads your paid
invoices as context and scores the open ones in one forward pass. There's no training loop and no tuning,
and nothing leaves the machine.

Who Would Pay for This

• Freelancers and small agencies with enough repeat clients that "who's going to be late?" no longer fits in their head, but not so many that they have a collections team.
• Bookkeepers who manage receivables for several small businesses. They can't paste a client's ledger into a cloud AI tool, and here they don't have to.

What they'd pay for is the next two weeks of chasing, decided in a minute, from their own history, with
nothing uploaded. The shape I'd sell it in is a one-time download, not a subscription, since there's no
server to pay for.

Demo

There's no hosted demo, on purpose: a hosted version would mean uploading your invoices. The repo ships a
demo built from a public dataset instead (details below). It takes the books as of Nov 1, 2013, hides
everything that happened after that date, and runs the tool:

On that snapshot it learned from 2,273 paid invoices (36% paid late), put the 12 already-overdue invoices
at the top, and ranked the other 67 by P(late), each with two plain-language reasons (e.g. "paid late on 17
of 17 past invoices") and a next step. The repo doesn't include the report or the dataset itself: IBM never
stated a license for the sample, so fetch_data.py downloads it and you generate the report locally.

Then check_demo.py compares that report with what really happened. Of the 67 invoices not yet due, 21 were
paid late. The top 14 by score held 10 of those 21. Nineteen were flagged at 50% or more, and 12 of them
were late. That's one snapshot of a few dozen invoices, so it shows how the report reads. It isn't
evidence. The evidence is the holdout below.

Code

./run_all.sh   # clean checkout -> venv, data + weights, holdout check, demo report (about 2 minutes on CPU)

How I Built It

Data. IBM's Accounts Receivable sample from its old Watson Analytics sample-data guide: 2,466 invoices
from 100 clients, issued 2012–2013, with invoice date, due date, amount, a dispute flag and the date each
was settled. 35.6% were paid late. IBM didn't publish a license for it or say whether the rows are real
customers or simulated, so the repo doesn't redistribute the file. fetch_data.py downloads it from a public
mirror and checks its SHA-256.

Inputs, as of the day each invoice went out: amount, amount vs. the client's usual, payment terms,
disputed or not, month, and the client's track record so far: invoices paid, share paid late, average days
late, how late the last one was, how many were still open or overdue, and days since their previous invoice.
Using only what was known on the issue date is the whole game. If you skip it, a model looks brilliant in
testing and useless on Monday.

Model: TabPFN-v2 classifier with three classes (on time / 1–7 days late / 8+ days late), so a single
model gives both "will it be late" and "how late":

from tabpfn import TabPFNClassifier
clf = TabPFNClassifier(model_path="models/tabpfn-v2-classifier-....ckpt", device="cpu",
                       random_state=0, ignore_pretraining_limits=True)  # >1,000 context rows on CPU
clf.fit(X_paid, late_class)              # "fit" = store the paid invoices as context
p = clf.predict_proba(X_open)            # columns: on time, 1–7 days, 8+ days
p_late, p_very_late = p[:, 1] + p[:, 2], p[:, 2]

On the holdout, fitting on 1,500 invoices and scoring 872 took 7.8 seconds on an 8-core CPU.

The holdout test. Time-based split at April 1, 2013. Training uses invoices issued and paid before
that date, the outcomes you'd actually have known, which is 1,500 invoices, 37.3% late. Testing uses every invoice
issued after it: 872 invoices, 30.0% late. (The late rate drifted down over time, so the test also checks how the model copes
with drift.)

What the table means in plain terms:

• Chasing a fifth of your invoices catches more than half the late ones. Picking the top 175 of 872 caught 56.5% of the 262 late invoices. A random fifth catches about 20%, and 66.8% is the most any method could catch with 175 picks.
• Most of the flags are right. 84.6% of TabPFN's top-20% were actually paid late.
• The percentages mean what they say. When TabPFN said 80–100%, 91% were late. When it said 0–20%, 6% were. Gradient boosting was overconfident at the top: it averaged 94% in that bin, and 80% were late.
• It beats the trained baseline, narrowly. In a paired bootstrap, TabPFN minus gradient boosting was +0.021 AUC (95% interval +0.010 to +0.031) with no tuning at all. A second clean run gave +0.018 (+0.007 to +0.029).
• "How late" works too. P(8+ days late) scored AUC 0.917 on the test set.

What the numbers don't show:

• How much of this is the dispute flag. 22.8% of test invoices were disputed, and 62.3% of those were late, against 20.5% of the rest. The data doesn't say when each dispute was raised. Without the flag, TabPFN scores AUC 0.875, gradient boosting 0.851, and "client's past late rate" 0.866. TabPFN's edge over that last one shrinks to +0.009 AUC, and in a second clean run its interval crossed zero, so there's no reliable edge there. Most of the signal is simply this client pays late. The model mostly adds well-calibrated odds and combines the weaker clues without any tuning.
• Real books. It's one dataset from 2012–2013, with every invoice on 30-day terms and amounts of $5.26 to $128.28. Nobody has run it on their own invoices yet.
• Bit-for-bit repeatability. TabPFN on CPU jitters between runs. A second clean run from a fresh clone gave AUC 0.914 instead of 0.917 and caught 56.9% instead of 56.5%. Both runs are saved in the repo, and the figures above are from the first.

Why Does Open Innovation Matter?

• The data never has to leave. A client ledger is exactly the kind of data you shouldn't upload. With open weights, the model runs where the data already is, with networking off after a one-time download.
• The license decides whether you can sell it. This was the most practical thing I learned building it. TabPFN-v2's weights are under Apache 2.0 plus an attribution clause, so a paid tool can ship with them. The newer TabPFN-2.5, 3 and 3.5 weights are non-commercial: fine for testing, not for a product, and not for "internal commercial decision-making" like deciding which client to chase. An open license is what makes the side hustle possible at all. Built with PriorLabs-TabPFN.
• We could audit it, not just trust it. Running the exact weights locally is how we found that the dispute flag carries much of the lift, and how we could publish that next to the headline number. A closed scoring API wouldn't let you check that on your own books.
• The rules stay yours. What counts as "chase now" is a business judgment, so it lives in five readable lines of Python, not in a vendor's settings page.

Prize Categories

• Best Use of TabPFN. TabPFN-v2 is the core of a small prediction agent: it scores every open invoice with a three-class model ("late" and "how late" in one pass), plain-language reasons come from re-querying the same model, and a rule layer turns the scores into next steps and draft reminders. On a time-split holdout it beat a default gradient-boosting model and a client-history baseline, with calibrated probabilities, no tuning, and everything on a laptop CPU.