Inspiration

UK small businesses get paid through PayPal and pay suppliers through it too, but the money arrives in their books by hand: someone downloads a report, works out which invoice each payment belongs to, splits off PayPal's fee, and hopes the VAT is right. Making Tax Digital means the VAT return has to come from digital records, so those hand-made entries end up in a tax filing. We wanted the PayPal side of a small business to keep its own books, without taking the owner's data into our database and without letting an AI post anything on its own.

What it does

Accnomos is built for UK businesses and the self-employed. It keeps their books in their own OneDrive or Google Drive and files VAT to HMRC; PayPal is where they get paid and pay their bills.

  • Get paid. Every invoice can carry a PayPal pay link: Accnomos creates a real PayPal invoice with the same lines, VAT and business details, puts the link on the PDF and in the email, and can send PayPal's own reminder.
  • Sync PayPal. Reads the PayPal account's transactions and proposes each one: gross, PayPal fee and net, matched to the invoice it pays. A sale with no invoice waits until the owner chooses its VAT. Nothing posts until the owner approves.
  • AI search in Ask (typed or spoken). "Did that client pay all the arrears? They had around £500 overdue — check PayPal." or "There was a PayPal payment last month, around £100 for stationery — how much exactly?" The AI turns the words into a search (who, roughly how much, which months, money in or out); code checks it, searches the books, Sync PayPal and PayPal's own transactions, and answers with the exact figure, date and payee, and whether it is in the books yet. "What did PayPal cost me this quarter?" and "How much is in PayPal?" are answered by code from the books.
  • Power grid (AG Grid Community). An optional add-on (Settings › Business › Power grid): the synced PayPal transactions in one sortable, filterable grid with totals, where the owner ticks several waiting rows and approves them together (each goes through the same checked approval), plus a ledger explorer where plain words such as "PayPal fees over £5 in October" become a grid filter. The AI only proposes the filter; code checks it against the allowed columns, and filters never change the books.
  • Tie-out. PayPal's own balance (with the time PayPal last refreshed it) against the PayPal account in the books, with the difference explained: waiting for approval, never posted (withdrawals, refunds, the opening balance), or unexplained.
  • Pay bills. On a supplier bill's due date, Accnomos offers to pay it with a PayPal Payout to the supplier's saved PayPal email. The owner approves; the payment posts only when PayPal reports SUCCESS (about 30 seconds in the sandbox). A retry can never pay twice.
  • Disputes. When a customer opens a PayPal dispute, Accnomos builds an evidence pack from the books (the invoice, the payment, the dates), checks every figure and date in the draft by code, and sends it only after the owner reads and approves it.
  • Help and support. A help centre with step-by-step guides, a support assistant that answers from them word for word and offers a ticket, and an admin queue; when PayPal is connected, a PayPal help panel shows the connection, last sync, open disputes and PayPal's own help links.
  • VAT. Approved PayPal sales are ordinary entries in the ledger, so they are in the VAT return Accnomos works out and files to HMRC (HMRC's sandbox in the demo).

Also in Accnomos: receipt and bill scanning (photo, PDF, email or a whole folder at once), bank feeds by Open Banking with reconciliation rules, invoices and quotes from plain words, MTD VAT (nine boxes, filed to HMRC), Income Tax figures for sole traders and landlords, CIS, month-end close, HMRC-ready reports and exports, a voice and typed assistant with Plan today, calendar and to-dos, jobs with costs and margins, mileage, payroll estimates, contacts with Companies House and VAT checks, goals, household money, accountant access, a marketplace sales add-on, and an Android app.

The rule throughout: the AI proposes, code calculates in pence, the owner approves.

How we built it

  • Web app: Next.js and TypeScript (apps/web), the PayPal screens on Invoices (Sync PayPal, tie-out, disputes) and Purchases (Pay bills with PayPal). Android app: Flutter (apps/mobile), the same runtime API, with Sync PayPal (VAT choice, tie-out), disputes, bill pay with upcoming payments and add to calendar, and AI search in Ask.
  • Power grid: AG Grid Community 36.3 (ag-grid-community, ag-grid-react; Community modules only, no licence key), loaded only when the owner turns the add-on on: apps/web/src/components/grid/PayPalReviewGrid.tsx (bulk approve with totals) and apps/web/src/components/grid/LedgerExplorer.tsx (plain-English filters, checked by apps/web/src/lib/grid-core.ts and services/runtime/app/ai/grid_filter.py).
  • Runtime: a stateless FastAPI service (services/runtime). It holds no customer database: each request carries the user's own drive token, and the books are files in the user's OneDrive or Google Drive, with an append-only ledger and a VAT engine that works in integer pence.
  • PayPal APIs used (services/runtime/app/payment_providers.py):
    • Invoicing v2: create, send, remind and cancel invoices; read an invoice back to find its payment.
    • Transaction Search (GET /v1/reporting/transactions, 31-day windows): the source for Sync PayPal.
    • Balances (GET /v1/reporting/balances): PayPal's own balance and its refresh time for the tie-out.
    • Payouts v1: one payout per bill, with a sender_batch_id derived from the bill, the amount and the attempt, so a retry after a lost answer returns the original batch instead of paying again; a bill posts only on SUCCESS.
    • Disputes v1: list and read disputes, provide evidence (notes plus a PDF from the books), send a message, accept a claim.
    • Two modes: partner mode (each business connects its own PayPal account through partner onboarding and PayPal-Auth-Assertion; written to PayPal's documentation, waiting for partner approval) and direct mode (the server's own sandbox REST app, used by the demo; it refuses live credentials).
  • AI at run time: a hosted AI model drafts proposals (coding a PayPal purchase to an account, wording a dispute response, explaining a figure), with Anthropic as the backup provider; an open-weights model can run on our own server or in local mode instead. Code works out every amount and checks every figure a model writes into a dispute response, and every posting is a proposal card the owner approves.
  • Tests: pytest against PayPal fakes written from PayPal's published schemas (services/runtime/app/online_fakes.py) and a mock transport; Playwright end-to-end tests for payment links; a smoke script that runs the same code against the real PayPal sandbox (tools/payments_sandbox_smoke.py).

Challenges we ran into

  • PayPal's reporting delay. Transaction Search can list a payment up to three hours after it happens, so a sync straight after a payment can show nothing. We show the balance's refresh time on screen and explain the gap in the tie-out instead of hiding it.
  • No future-dated payouts. PayPal Payouts send at once, so "pay on the due date" means Accnomos pays the next time it is open on or after that date (writing to the books needs the owner's sign-in, so there is no overnight job).
  • The real sandbox disagreed with the docs. Invoice create answered with only a self link, so the invoice id is read from it; the duplicate-payout refusal links the original batch inside details[].link. Both are fixed and noted. A payout to a registered sandbox account then went from PENDING to SUCCESS in about 30 seconds.
  • Fees and VAT. PayPal's fee is VAT-exempt and comes out of the gross, so each payment becomes three figures and a clearing account (1240 PayPal clearing) that the bank payout later clears, so money is never counted twice.

Accomplishments that we're proud of

  • The whole loop runs on one set of books the owner owns: invoice, PayPal payment, fee, tie-out, supplier payout, dispute evidence, VAT return.
  • Nothing reaches the ledger without the owner's approval, and an AI never does the arithmetic.
  • A retried payout cannot pay a supplier twice, and a changed supplier payment detail on a bill is flagged, never copied into the payee list.
  • An honest record of what has met PayPal's real sandbox and what has only met fakes (docs/HONESTY.md).

What we learned

  • Reporting APIs and payment APIs run on different clocks; reconciliation has to show "as of" times, not pretend to be live.
  • Idempotency keys have to be derived from the business event (bill, amount, attempt), not generated per request, or a retry is a second payment.
  • Writing fakes from the published schemas first, then running against the sandbox, found the two places where the sandbox's answers differ from the documentation.

What's next

  • PayPal partner approval, so each business connects its own PayPal account (partner mode is written and tested against fakes).
  • Run the remaining calls against the sandbox: Invoicing remind, itemised invoices, Disputes and the capture read for the fee.
  • PayPal webhooks, so payments are proposed without opening the app.
  • Connecting PayPal and saving supplier PayPal emails from the phone (both are on the web today).

Built with AI

Claude (Anthropic) was the coding assistant: it wrote most of the code under the owner's direction; the owner set the requirements, reviewed the work and made every product and compliance decision. Inside the product, a hosted AI model (Anthropic as backup) or an open-weights model on our own server proposes; code calculates every amount in pence; the owner approves every posting.

Try it: https://accnomos.com (Try the demo, no sign-in) · Code: https://github.com/zaytunazs/accnomos · Judges' guide: docs/submission/paypal/JUDGES.md

Built With

Share this project:

Updates

Submission history