Receivables automation without a POS API

A South Florida specialty food manufacturer sells wholesale on account to around seventy-five restaurant and retail customers.

Chasing those invoices was manual and inconsistent. One person kept the receivables spreadsheet, followed up by phone when he remembered, and every day retyped the day’s wholesale invoices out of the point-of-sale receipts report into that same sheet.

Chains made it worse: several locations, one accounts-payable inbox, and no way to send a single consolidated claim.

Two reminder stages: a heads-up between day twenty-one and day thirty, and an overdue notice from day thirty-one.

Reminders group by email address rather than by customer, because chains share one accounts-payable inbox. A customer with twelve open invoices gets one email with a table of twelve, not twelve emails.

Five workflows in total: reminders, automated invoice loading from the POS report, a daily digest to the operator, new-customer onboarding, and payment reconciliation.

The client decided against licensing the point-of-sale API. At their volume the cost did not justify it, and that decision was made before I scoped anything.

So the integration does not call an API at all. It reads the report the POS already emails on a schedule, parses it, and loads the day’s wholesale invoices from there. That kept the recurring cost at zero and the build inside the budget.

The second decision matters as much: the logic lives in the client’s own spreadsheet, not in the automation platform. A sheet fills itself with exactly the invoices to claim today, already matched to the contact email and the notice type. The person who runs it can audit what the system is about to do by looking at his own spreadsheet, without opening the automation tool.

There is no external state store either. What was sent is recorded in two columns of that same sheet, so the system’s state cannot drift out of sync with the business’s state.

On an SMB engagement this is most of what architecture is: not picking the best integration in the abstract, but the best one the client will actually pay to keep running.

The system was tested against ninety days of real history — four hundred and twelve invoices — against what the operator had actually entered by hand.

That run caught a real defect. The first filter selected wholesale invoices by customer profile and silently lost twenty-seven of them: legitimate wholesale invoices had been booked under the retail profile, depending on which button whoever took the order happened to press.

Customer profile was never a reliable discriminator. Payment tender was. Filtering on tender reproduced the operator’s manual entry exactly.

A single day’s report was then validated end to end: of fifty-four receipts, the five wholesale invoices were extracted, names normalized, and due dates computed correctly.

Live. The five workflows run every day and give the operator back thirty to forty-five minutes a day: the time he used to spend retyping the day’s invoices and working out who to chase.

Delivered with a go-live runbook, an end-user guide written for the person who runs it daily, a weekly reconciliation procedure, the data-quality analysis behind the spreadsheet, and an incident log.

A validation set is not a formality. Running the system against what a person actually did, rather than against what the process says they do, is what surfaces the discriminator nobody wrote down.