Skip to content

EP Finance Receipts

EP Finance Receipts turns the photo of a receipt into an expense before its bank line has even arrived.

This page documents EP Finance Receipts 0.1.8.

Published by ElmsPark Studio.

  • PageMotor 0.9b or later
  • EP Finance, which holds the ledger this plugin reads and writes

A mobile-friendly page that opens the camera on a phone. Photograph the receipt when you get it, not three weeks later when you are trying to remember what it was for.

If you have an AI provider configured, the plugin will attempt to read the payee, date, total and VAT from the image and fill the form in for you. If you have not, you type them. There is no dependency on AI: it is an assist, not a requirement, and you can correct anything it reads.

When the bank line for that receipt eventually arrives, the plugin looks for a match on a date window and an exact amount, and proposes it. It does not link them silently. You confirm, and only then is the image attached to the reconciled transaction.

This matters because a wrong automatic match is very hard to spot later and very easy to make: two similar amounts a day apart is all it takes.

A receipt with no VAT number on it is flagged as not being VAT evidence. That is a fact about the receipt, not a judgement about your return, and it is there so you find out before your accountant does.

Receipt photographs are financial personal data. They are never placed anywhere a browser can reach directly: the bytes live in the database or in a folder outside the web root, and they are streamed only through a handler that checks you are an administrator first.

There is a retention setting, and the plugin honours EP GDPR delete requests.

  • Settings language menu. The language menu in this plugin’s settings now lists only the languages it is actually translated into, plus English, so you can no longer pick a language that changes nothing.
  • The plugin description no longer advertises AI extraction of receipts. AI pre-fill has been switched off since 0.1.14; receipts are entered by hand.
  • A receipt kept after a GDPR erasure no longer carries a file name that could identify the person. Since 0.1.15 a receipt already matched to a transaction is kept as your tax record, with the person’s email and notes removed. Its photo’s file name stayed, and a photo can be named after the person (for example “Jane Smith taxi.jpg”). It is now renamed “receipt-” and its number, on the receipt and on its copy in your books. The “Not VAT evidence” label stays.
  • An amount too large for your books is refused, and the page says so. An amount of 10 trillion or more (almost always a slip, such as a long number pasted into the wrong box) used to be saved as 0.00, or the page said “add at least the amount”. The phone capture page, the Add receipt tab and the API now refuse it, say whether the amount or the VAT amount is too large, and keep what you typed so you can correct it.
  • If the optional AI pre-fill ever reads an amount that large from a photo, it counts as not read, so you type the amount yourself.
  • Receipts come back when their transaction is deleted. If you delete, in EP Finance, a transaction a receipt was matched to, the receipt now goes back to Pending with a fresh suggested match, and the Pending tab says why. Before, it stayed “matched” to nothing and never came back for matching.
  • A receipt whose suggested match was deleted gets a new suggestion.
  • A GDPR erasure request no longer deletes receipts that are part of your books. A receipt matched to a bank transaction is your record of that expense, which tax law says you must keep for your retention period. When someone asks for their data to be erased, those receipts are now kept with their photo, but with the person’s email and notes removed, so they are no longer linked to them. They are deleted automatically when the retention period ends, like every other receipt.
  • Everything else of theirs is deleted as before: receipts not yet matched, and receipts already past the retention period.
  • The erasure result shows how many receipts were kept as tax records, and until when.
  • The Tools tab explains this under Retention.
  • Money coming in is no longer offered as a match for a receipt. A receipt is money you spent, so only bank lines where money went out (from a bank account or a credit card) are proposed, and only in the receipt’s currency. Before, a £300 payment from a customer could be proposed for a £300 expense receipt.
  • Confirming a match is checked properly. A receipt can only be confirmed to an imported bank line that paid out exactly its amount. Clicking Confirm twice, or two people confirming at once, can no longer attach the same photo twice or put two receipts on one bank line.
  • New: Unmatch. A matched receipt on the Pending tab now has an Unmatch button. It takes the receipt’s photo off the bank transaction and puts the receipt back to pending, ready to match again. Ledger amounts are never changed.
  • A photo shared by two receipts is no longer deleted while one of them still needs it. When receipts are kept in a storage folder, two identical photos are stored once. The retention purge and a GDPR erase now remove the file only when no other receipt still uses it.
  • A very long payee, VAT number or email no longer stops a receipt being saved. It is shortened to fit instead. If a receipt still cannot be saved, the phone page now says so, rather than asking you to add an amount, and the photo it had stored is removed.
  • AI pre-fill of receipt details is switched off for now. The AI connection could only be given the photo’s file name, not the photo itself, so any figures it filled in would have been guesses. Receipts are entered by hand, which is how the plugin already worked unless EP Assistant offered pre-fill.
  • The review queue now keeps up with your bank imports. Before, a receipt was checked against your bank lines only once, when you added it. If its bank line arrived later, the receipt still sat in the review queue as “no matching bank line”. If the bank line it had been matched to went to another receipt, it never reached the queue at all. Each time the queue is opened it now checks those receipts again, so a receipt leaves the queue once its bank line is imported and joins it when its match is taken.
  • A new receipt is matched using your “Match window” setting. It used to look only 3 days either side of the receipt date, whatever the setting said. “Find match” already used your setting.
  • “n/a”, “none”, ”-” and similar in the VAT number box now count as no VAT number, so the receipt is flagged “not VAT evidence”. Receipts you already added this way are corrected once after the update.
  • Where the “not VAT evidence” flag shows up. When a flagged receipt is matched, its photo on the bank transaction is now named “[Not VAT evidence] …”, so the receipts list in a tax pack’s accountant export shows the flag. Please note: the tax packs’ VAT figures do not yet leave these receipts out. Check the flagged receipts (the “No VAT” count on the dashboard tile) before you claim input VAT on them. Earlier notes and help text said the tax packs acted on the flag; they did not, and this has been corrected.
  • Deleting a receipt now also deletes its photo from the matched bank transaction. This applies to erasing a person’s data through EP GDPR and to the retention purge. Before, the photo of a matched receipt stayed in the database for ever. The retention purge still only removes receipts older than your “Keep receipts for” setting, so photos inside that period stay on their transactions.
  • “Clear all receipts” (Tools tab) now asks you to type DELETE before it runs, and it is checked on the server too, so a stray click can no longer wipe your receipts. It now also removes the photos it had attached to matched bank transactions. Ledger amounts are never changed.
  • A receipt photo that could not be saved is no longer reported as saved. On some database servers a large photo (several megabytes) is refused when it is stored. Until now the capture page still said “photo attached”, and the photo was simply missing when you went to view it. The receipt is now recorded without the photo and the page says “no photo”, so you know to capture it again, for example at a smaller size.
  • The one-off move of older receipt files no longer deletes a file it failed to copy. When receipts stored in the old folder are moved into the database, the original file is now removed only once the copy is confirmed.
  • The download no longer includes an internal notes file. Earlier versions carried a CLAUDE.md file of developer notes in the plugin folder. Neither the plugin nor PageMotor ever read it, so nothing about how the plugin works changes. If an earlier version left ep-finance-receipts/CLAUDE.md on your site, it is harmless and safe to delete.
  • Fixes a doubled cache-busting tag on its admin script. On PageMotor 0.11 and later the page asked for the file with two version tags on the end of its address (?v=…?v=…), because the core had started adding its own tag and the plugin was still adding one too. The file loaded correctly, so nothing was visibly broken; the address was just malformed and every cache saw a longer key than it needed. The plugin now leaves the tag to the core on 0.11 and later, and still adds its own on older cores, where nothing else would.
  • No change to what that script does.
  • Works with PageMotor 0.11.3 and stays compatible with earlier releases. PageMotor 0.11.3 changed how a plugin declares its API and MCP actions, and a plugin that still uses the old declaration has every one of its actions silently dropped from the registry on that version. This release declares its actions in the shape the running PageMotor expects, so an AI connected over API or MCP keeps every action whether the site is on 0.11.3 or on an earlier release.
  • Actions are now grouped into families, so a connected AI that looks up one action is shown its siblings.

Released 1 September 2026.

  • Some of this plugin’s actions used to appear as their own entries in the tool list of any connected AI client. That surface is reserved for PageMotor itself, so those entries have been removed.
  • Nothing became unreachable and nothing else changed. Every action still works exactly as before through PageMotor’s own dispatch, with identical responses. Only a caller that had been invoking one of those names directly is affected, and it should dispatch through PageMotor instead.