Pharmacy Payments Platform — Built Twice, Better the Second Time
Built a month-end payment calculation system for a pharmacy delivery company, then rebuilt it as a full customer data platform when Xero changed their API limits and broke the original solution. The second version gave both pharmacies and the business real-time visibility on orders and amounts owed — something the first version never had.
Outcomes
3-week manual close → books closed day 1
API limit crisis → turned into a product
Both sides: full real-time payment visibility
The Problem
A pharmacy delivery company needed to calculate exactly what each pharmacy was owed at month end — factoring in complex product rules, compliance requirements, and daily order aggregations. Finance was doing this manually. It took weeks to close the books and errors were common. The stakes were high: this is medicines, and accurate payments to pharmacies are non-negotiable.
The Approach
Built a comprehensive SQL semantic model for pharmacy product rules — every SKU, every pricing tier, every compliance rule codified and tested.
The daily aggregated payment amounts were pushed directly to Xero as bills — one bill per pharmacy per day. Finance went from weeks of manual work to a fully automated close.
Then Xero changed their terms of service and introduced hard API transaction limits. The system we built — generating hundreds of daily bills — now exceeded those limits.
Rather than patch the existing system, I built a middleware customer data platform. Pharmacies and business operations both got a real-time view of orders placed and amounts owed — a proper UI with actual visibility, not just a spreadsheet.
Only at month end does a single journal entry go into Xero — one transaction, well within the API limits, recording the finalised settlement amount.
The Result
The Xero API crisis turned into a better product. Both sides — pharmacies and the business — now have real-time visibility on what's owed and why, which the original system never provided. Month-end close is same-day. And the architecture is resilient: no dependency on a third-party API for daily operations. The lesson: when an external constraint forces you to rethink the design, the new design is usually better.
Full Stack
Interested in something similar?
Let's talk →