A folder full of receipts does not tell you which bank payments still need evidence. A list of payments does not tell you which uploaded documents remain unmatched.
Build the review around those two gaps. In Notion, keep Transactions and Receipts as separate databases, connect reviewed records, and create queues for the exceptions.
The practical payoff is a shorter weekly task: inspect what is unresolved instead of opening every document again. This guide focuses on that review process, rather than treating “a file exists” as proof that a payment is explained.
Reviewed on 1 November 2026. The records below are illustrative; this is an evidence-management workflow, not tax advice.
Give each exception a home
| Queue | What belongs there | What resolves it |
|---|---|---|
| Payment needs evidence | A purchase requiring a document, with no reviewed link | Correct receipt linked or an explained exception |
| Document needs a payment | An extracted receipt with no confirmed bank match | Matching transaction or another payment method recorded |
| Difference needs explanation | Amount, currency or timing does not align | Reviewed reason and any allocation |
| Ready for review sign-off | Evidence and explanation complete | Named reviewer and review date |
Keep source facts and review decisions separate
In Transactions, preserve the bank date, amount, account, currency and description. Add review fields such as Evidence required, Receipt relation, Review status, Reviewer and Exception note.
In Receipts, keep a document reference, source link, extracted date, merchant, total and currency. Add a verification status so an AI-extracted amount does not look indistinguishable from a checked value.
BankSync's Notion integration guide explains the destination sharing and property mapping. Its Document Extractor guide describes receipt extraction and delivery to connected destinations. Configure the transaction and document flows deliberately; they represent different kinds of records.
Do not assume that creating those two feeds also creates or fills the relationship between their rows. Matching is a separate step in this design.
Build the first review queue
Create a receipt relation
Add a Notion relation between Transactions and Receipts; enable the reciprocal property if reviewers need navigation from both sides.
Define evidence requirements
Mark the kinds of payments that your process expects to have documents. Do not mark every transfer as a purchase.
Add review states
Use a small set such as Unreviewed, Waiting for evidence, Difference to explain and Reviewed.
Create filtered views
Show unresolved payments and unlinked receipt records separately.
Test three cases
Use one clear match, one missing receipt and one amount difference before expanding the workflow.
Notion's relations documentation explains how to link pages. Its view documentation explains filters and sorting. The queue definitions here are a suggested process you configure, not a built-in BankSync matching engine.
For the first pass, use a small period such as one reviewed week. Decide what “Reviewed” means before people begin: for example, source document opened, key details checked and any difference explained.
A small review batch
| Bank payment | Evidence | Decision |
|---|---|---|
| −£84 stationery | Receipt total £84, same currency and plausible date | Link and mark reviewed |
| −£29 software | No document yet | Request or retrieve evidence |
| −£52 meal | Receipt total £48 | Check tip or another explanation |
| −£300 savings transfer | Movement between owned accounts | Classify transfer; no purchase receipt expected |
| +£20 refund | Credit document or original purchase context | Link and explain refund separately |
Make one-to-many cases explicit
One bank payment may cover several documents. One document may be settled by several payments. A relation can preserve those links, but the total of every linked document is not necessarily the amount of this particular payment.
For example, an invoice for £600 paid in two £300 instalments should not be reported as £1,200 of spending because it appears beside both payments. Keep the bank movements as the cash record, and introduce allocation amounts when you need to measure how much of a document each payment settles.
For simpler household purchases, a direct relation may be enough. For business allocation, define the settlement amount and remaining amount explicitly rather than relying on a count of linked documents.
If you prefer to keep the working data in BankSync, Tables relations offer a separate native implementation. A BankSync relation links rows within its workspace; it is not the same field as a Notion relation.
Review extraction before relying on it
Open the original document and compare merchant, date, currency and total. A clear image helps, but a successfully processed document can still contain an incorrect extracted value.
Preserve the original document reference when correcting a value. If the same receipt arrives by email and manual upload, investigate the apparent duplicate before it is counted twice or linked to two unrelated payments.
Do not make a clean queue your only success measure. An empty queue caused by a restrictive filter or an overly broad “Reviewed” update is worse than a visible list of real exceptions.
At the end of a review, sample a resolved item and reopen both the transaction and evidence. The relationship should still make sense to someone who did not perform the matching.
A useful weekly handover
| Measure | What it tells you | What it does not prove |
|---|---|---|
| Payments awaiting evidence | Remaining document work | That every payment requires a receipt |
| Unlinked receipts | Remaining matching work | That the bank feed is wrong |
| Unexplained differences | Cases needing judgement | That every difference is an error |
| Reviewed records | Completed process steps | Tax eligibility or accounting treatment |