Flowgrammer

Invoice Tracker

Build an invoice tracker with required fields, statuses, duplicates, exceptions, and a human approval boundary before posting or payment.

— Craig Major

An invoice tracker is a register of supplier invoices. Each row records who sent the bill, what it is, what state it is in, who owns the next action, and whether it is a duplicate or an exception. The tracker does not post the bill to accounting and it does not pay anyone. A person still approves the invoice before any of those actions happen outside the register.

This guide covers the register: status, owner, duplicates, exceptions, and approval history. The intake-to-draft workflow, including extraction and idempotent accounting writes, stays on Invoice Processing Automation. The first-document-type plan stays on Document Processing Automation. The Invoice Tracker Starter Pack is the paired field list, sample register, and setup map.

Who this is for

Use this when invoices already arrive and the immediate problem is visibility: what came in, what is waiting, what is overdue, and what must not be entered twice.

Prerequisites:

  • One buying entity for the first register. The worked example is fictional Cedar & Quay Fabrication Ltd.
  • One owner who can assign reviewers
  • A written rule for what counts as a duplicate
  • A place to keep the source file or a durable link to it
  • Agreement that posted and paid are recorded after a person acts in another system

Stay out of the first tracker: supplier bank-detail changes, tax filings, autonomous payment, and multi-entity matching.

If you still need to choose which document family to automate first, start with the pillar. If you need the extraction and draft-write path, use the invoice-processing guide and the live Invoice Processing Test Pack.

What an invoice tracker is

A tracker is the operating list. It answers five questions about every invoice:

  1. Did we receive it?
  2. Is the row complete and mathematically consistent?
  3. Have we already seen this vendor and invoice number?
  4. Who must approve it, and what did they decide?
  5. What is the current status, including overdue and exception states?

Microsoft's vendor-invoice reference architecture keeps a tracking list while a pending vendor invoice is created in the ERP. Dynamics documents a vendor invoice register, pending vendor invoices, and a later posting step as separate actions. Use that separation. The register is not the posted bill.

This is an accounts-payable status tracker. It records bills you received. It is not a sales-invoice document you send to a customer. If you searched for a Google Sheets invoice template, you probably want an accounts-receivable layout with your logo, line items, and a sendable PDF. That is a different job from this register.

Google Sheets, Notion and Airtable do not extract invoice fields from PDFs by themselves. They can store or link the files. They do not create QuickBooks or Xero drafts, do not certify an AP approval product, and do not pay anyone. Extraction and destination writes stay on the invoice-processing page. Payment stays outside this workflow.

Tracking versus posting or paying

Action What it means Where it belongs
Track Record the invoice, status, owner, exceptions, and decisions Invoice tracker
Validate Check required fields, totals, and duplicates Tracker rules, before approval
Approve A named person accepts or rejects the invoice Tracker decision, human only
Post Create or release the accounting draft or vendor invoice Accounting system, after approval
Pay Disburse cash or schedule a payment Payment system, after posting and a separate authorization

Dynamics can block submission when an invoice number already exists on a posted invoice. That control lives at the accounting boundary. The tracker should have already stopped the same vendor plus invoice number. Do not treat a status change to posted or paid as proof that the destination write or the payment happened. Those statuses are recorded after a person confirms the external action.

Minimum fields every tracker needs

Start with the fields that make a row identifiable, reviewable, and auditable. Add tax and line detail when the source invoice or your later accounting map needs them.

Field Why it is required Notes
record_id Stable row identity Do not reuse after a reject or void
vendor_name Who billed you Pair with a vendor_id once you have a vendor list
invoice_no The supplier's invoice number Required before approval unless a person overrides
invoice_date When the supplier dated the bill Needed for aging and source checks
received_date When your team captured it Different from invoice_date
due_date When payment would be late Drives overdue views. Empty is an exception if terms exist
currency What the amounts are in Do not mix currencies in one total column without a label
subtotal, tax, total Arithmetic and review Flag when subtotal + tax does not match total
status Current operating state Use the closed list below
owner Who is responsible now Empty owner on an open row is a failure
reviewer Who may approve Can be the same person in a one-person team
source_ref File name, message id, or folder path Keep the original
duplicate_key Normalised vendor plus invoice number Compute it. Do not type it by hand
exception_code Why the row is not clean Empty when there is no exception
approval_decision approve, reject, hold, or blank Blank means not yet decided
posted_ref Destination id after a person confirms the write Stays empty until that confirmation
paid_ref Payment id after a person confirms payment Stays empty until that confirmation
last_event_at When the row last changed Start of the audit trail

Canadian buyers who later claim input tax credits also need prescribed information on the source document. CRA GST/HST Memorandum 8-4 states that supporting documentation must include the supplier name, invoice date, and total at every amount; the supplier GST/HST registration number once the amount is $30 or more; and, at $150 or more, the recipient name, terms of payment, and a brief description of what was supplied. Those are documentary requirements for an ITC claim. They are not a licence for the tracker to file tax or to invent a missing GST/HST number.

The Invoice Tracker Starter Pack uses one shared field list for Google Sheets, Notion and Airtable. Keeping the same names and statuses makes imports, reporting and later migrations easier. You may add app-native views or automations.

Worked example

Cedar & Quay Fabrication Ltd is a fictional Toronto buyer. On 8 September 2026 it receives Ridgemont Industrial Supply Co invoice INV-TP-2401 for safety vests, clipboards, and fastener bins. Subtotal CAD 400.00, HST CAD 52.00, total CAD 452.00, due 8 October 2026.

The tracker row starts as received with owner Maya Chen (fictional). Validation checks the required fields and confirms 400.00 + 52.00 = 452.00. The duplicate key is ridgemont industrial supply co|inv-tp-2401. No earlier row matches, so the status becomes pending_approval. No posted_ref and no paid_ref exist.

The same afternoon a second file arrives with the same vendor and invoice number. The tracker marks that second row duplicate and does not send it to a reviewer. The first row stays in approval.

Two other rows from the live test pack belong in the same register as exceptions: Ashbridge Print Works with a blank invoice number, and Prairie Bolt & Fastener Ltd invoice INV-TP-2404, where subtotal plus tax is 220.50 and the printed total is 185.00. Those rows wait. They are not posted.

The companies, people, and GST/HST numbers in this example are fictional. They are not customer results.

The register workflow

  1. Intake. Create one row when the invoice arrives by email, folder, form, or handoff. Store received_date, source_ref, and the owner. Do not wait until someone is ready to post.
  2. Validate. Check required fields and arithmetic. Required before approval: vendor, invoice number, invoice date, currency, and total. Check that subtotal plus tax matches total within 0.011, the same rounding tolerance used in the invoice-processing test pack.
  3. Detect duplicates. Compare the new duplicate_key with open and closed rows. A second file with the same vendor and invoice number is a duplicate even when the bytes differ. A replay of the same file is also a duplicate.
  4. Route exceptions. Missing invoice number, conflicting total, unknown vendor, missing owner, or missing source file go to an exception view. They do not advance to approval unless a person records an override.
  5. Approve. A named reviewer chooses approve, reject, or hold. Approval means the register row is trusted. It does not create the accounting draft.
  6. Track status after approval. The row stays approved until a person records a destination id from the accounting system. Payment is a later, separate confirmation.
  7. Watch overdue items. If due_date has passed and the row is not paid, rejected, or duplicate, it belongs on the overdue view with a follow-up owner.
  8. Keep history. Every status change, exception, override, and external reference is an audit event. Do not overwrite the previous decision.

What can run automatically, and what cannot

Situation Automatic action Person required
New file or form creates a row Yes Confirm the source if intake is messy
Required fields present and totals add up Move to pending_approval Yes, before any accounting action
Duplicate vendor plus invoice number Status duplicate. No approval queue Only if a later written policy allows an override
Missing invoice number or conflicting total Status exception Yes. Hold unless a person overrides
No reviewer assigned Stay pending_approval or return to exception Yes. Do not skip to approved
Reviewer approves Status approved The approve decision itself
Accounting draft created in another system Record posted_ref only after a person confirms Yes. The tracker does not post
Payment sent in another system Record paid_ref only after a person confirms Yes. The tracker does not pay
Due date passed on an open approved row Flag overdue and list a follow-up owner Yes, for contact or hold decisions

Human gates

A person keeps these decisions:

  • Who owns the row
  • Whether a duplicate or exception may continue
  • Approve, reject, or hold
  • Whether the row may be marked posted after an accounting write
  • Whether the row may be marked paid after a payment
  • Whether an overdue item is escalated, put on hold, or left in follow-up

The tracker must not create a vendor bill, release a payment, change supplier bank details, or treat a formula result as approval.

Failure paths

Failure Expected status Next action
Missing vendor, invoice number, date, or total exception Collect the field. Do not approve
Subtotal plus tax does not match total exception (conflicting_total) Check the source. Override only with a named decision
Same vendor and invoice number already exists duplicate Stop. Do not create a second approval
Unknown vendor exception (unknown_vendor) Confirm the supplier before approval
No owner on an open row exception (missing_owner) Assign someone
Source file missing exception (missing_source) Recover the file or reject
No reviewer Stay pending_approval Do not mark approved
Status jumps from received to posted Invalid Return to pending_approval
Tracker used to send payment Prohibited Stop. Use the payment system after approval and posting
Overdue with no follow-up owner Open overdue failure Assign follow-up the same day you see it

Overdue items, exceptions, and audit history

Overdue is a view, not a separate invoice. Use due_date against an explicit as-of date. In the starter pack that date is a cell you can change. Do not hide overdue rows that are still approved or pending_approval.

Exceptions stay on the same register. Do not move them to a private spreadsheet. The first exception codes to implement are missing_invoice_no, conflicting_total, duplicate, unknown_vendor, missing_owner, missing_source, and missing_tax_id.

Audit history is the reason you can defend the register. Record who changed the status, the previous value, the new value, the reason, and the timestamp. Notion's last-edited properties and Airtable's last-modified fields can support that, but they are not a full decision log. Keep an event list if more than one person can approve.

Choosing Google Sheets, Notion, or Airtable

These are implementation choices for the same register. This guide does not rank them and it does not ship a live product template for any of them.

Need Google Sheets Notion Airtable
Fast table with totals and aging Strong. Formulas, QUERY, and dropdown data validation are documented Possible with number, date, status, and formula properties Strong. Typed fields include date, currency-style number, single select, and formula
Status and ownership Dropdown lists plus a people column you maintain Status property with To-do, In Progress, and Complete groups; Person property Single select plus a user or text owner field
Views Filter views or QUERY tabs Table, board, calendar, and filtered views Grid, calendar, kanban, and other views
Source files Drive links or a folder plus source_ref. Images in cells are not a PDF store File property Attachment field. API download URLs expire in about two hours and are not a public CDN
Reminders and handoffs Manual, or later Apps Script Paid-plan database automations can notify people or send a webhook Automations can trigger on create, update, condition, or a view
History and protection Protected ranges exist. Google says they should not be used as a security measure. People can copy or export a protected sheet Page version history is plan-dependent: 7 days on Free, 30 on Plus, 90 on Business, and longer on Enterprise Base permissions and attachment viewer links that require Airtable access. Do not treat download URLs as permanent
What it will not do OCR, certified AP approval, accounting drafts, or payment OCR, certified AP approval, accounting drafts, or payment. Automations cannot trigger other automations OCR, certified AP approval, accounting drafts, or payment

Google Sheets documents in-cell dropdowns through data validation and filtered tables through QUERY. Its help page on protecting sheets states that protection should not be used as a security measure. Notion documents Status, Person, Date, Number, File, Relation, and last-edited properties, plus paid-plan automations that edit properties, notify people, send mail, or send a webhook. Notion's version-history depth depends on the plan. Airtable documents typed fields, automations, and attachment URL behaviour: download URLs stay active for at least two hours and are not a permanent public file store.

Pick Sheets when one operator wants formulas and importable CSVs first. Pick Notion when the same workspace already holds the approval conversation. Pick Airtable when you want typed fields and views before you write any integration. Keeping the same names and statuses makes imports, reporting and later migrations easier.

When a tracker is no longer enough

Keep the tracker while one team, one intake path, and one destination are enough. Move to a Document Intake and Approval System when any of these are true:

  • Invoices arrive from more than one mailbox, folder, or form and rows are being created twice
  • Reviewers need routing rules, escalation, or an audit trail that a shared sheet cannot protect
  • Approved rows must create a draft in accounting without a person retyping the bill
  • Exception volume is high enough that people work only from a queue
  • You need extraction, confidence checks, and retries from the invoice-processing workflow

The template handles tracking. The system handles the handoffs.

Test cases

Use these tracker cases on paper first. The starter pack includes the same rows as importable CSVs.

Case Input Expected register result
Clean received invoice INV-TP-2401, CAD 452.00, all required fields received then pending_approval after validation. No posted or paid reference
Duplicate Second row with Ridgemont and INV-TP-2401 duplicate. No approval. First row unchanged
Missing invoice number Ashbridge Print Works, blank number, CAD 257.64 exception / missing_invoice_no. No approval unless a person overrides
Conflicting total INV-TP-2404, printed total 185.00 versus 220.50 exception / conflicting_total
Overdue approved invoice Due date before the as-of date, status approved, no paid_ref Appears on the overdue view with a follow-up owner
Posted recorded too early Status set to posted while approval_decision is empty Invalid. Return to pending_approval
Payment attempted from the tracker Any payment action inside the register Rejected. Tracker records paid_ref only after a person confirms an external payment

The live Invoice Processing Test Pack covers the destination-write cases this register does not: a clean approve that creates one accounting draft, and a timeout that retries the same idempotency key. Keep those outcomes on the processing page. Keep the register states here.

What to measure

Count open rows, rows in exception, duplicate stops, rows waiting on approval, overdue rows, median hours from received_date to approval, and how often posted_ref is filled in the same week as approval.

Do not convert those counts into a savings claim. The Automation ROI Calculator is a planning worksheet. Replace its illustration with your observed numbers.

This article does not report a live production metric.

How the Invoice Processing Test Pack fits

The test pack is the parent acceptance suite for extraction, validation, duplicates, human approval before a draft write, and a lost destination response. The tracker is the register those invoices land in.

Use the pack like this:

  1. Run the five fictional cases against your extractor or against the labeled fixtures.
  2. Create one tracker row per case, including the duplicate.
  3. Confirm the register statuses match the table above.
  4. Do not mark a row posted because an extractor succeeded.
  5. Only after a person approves, use the processing workflow to create one accounting draft and store the destination id in posted_ref.

The test pack does not replace the tracker. The tracker does not replace the test pack.

How to use the starter pack

The paired Invoice Tracker Starter Pack is a platform-neutral kit: a field dictionary, status model, role matrix, duplicate and exception rules, overdue rules, dashboard metric definitions, fictional sample rows, importable CSVs, and an editable workbook. It also has a setup map for copying that structure into Google Sheets, Notion, or Airtable.

  1. Open the starter pack and download the ZIP.
  2. Open the field dictionary and status model.
  3. Import the invoices CSV into a blank sheet or table.
  4. Walk the seven test cases above against the sample rows.
  5. Copy the field types into the tool you already use.

The pack is not a duplicable Notion template or a live Airtable base. The starter pack uses one shared field list for Google Sheets, Notion and Airtable. Keeping the same names and statuses makes imports, reporting and later migrations easier.

Next step

If invoices already have owners, statuses, and a single workspace, stay on the tracker until the handoffs hurt.

If documents arrive through several channels, need named approvers, or must update another system after the register is correct, scope a Document Intake and Approval System through AI Automation Systems. Bring the field list, the exception codes, and a week of redacted tracker rows.

If several document workflows are competing and the first build is unclear, use the AI Success Audit. That is the existing audit with a document-workflow focus.

Sources

Frequently asked questions

What is an invoice tracker?

It is a register of supplier invoices with required fields, a status, an owner, duplicate and exception flags, and a record of who approved the row. It does not post or pay the invoice.

Is an invoice tracker the same as invoice processing automation?

No. The tracker keeps state and history. Invoice processing automation moves a file through extraction, validation, review, and a reviewed accounting draft. You can run a tracker without extraction. You should not post without a tracker or an equivalent register.

Which fields does every invoice tracker need?

Vendor, invoice number, invoice date, received date, due date, currency, subtotal, tax, total, status, owner, reviewer, source reference, duplicate key, exception code, approval decision, and later posted and paid references. Add GST/HST registration and line descriptions when the source invoice and your records process need them.

What is the difference between tracking an invoice and posting it?

Tracking records the bill and the decision. Posting creates the accounting document. Payment is a third action. Microsoft's pending vendor invoice and invoice register sit before posting. Your tracker should stay on the same side of that line.

How should duplicates be handled?

Key vendor plus invoice number. If that key already exists, mark the new row `duplicate` and leave the first row alone. Do not send the duplicate to approval. A later override needs a written policy and its own test.

Is an invoice tracker the same as a Google Sheets invoice template?

No. A tracker is an accounts-payable status register for bills you received. A sales-invoice template is a document you send to a customer. If you searched for a Google Sheets invoice template, you probably want the sendable document, not this register.

Do Google Sheets, Notion, or Airtable extract, post, or pay invoices?

No. They can store or link invoice files and hold status, owners, and views. Google Sheets, Notion and Airtable do not extract invoice fields from PDFs by themselves. They do not create an accounting draft, they are not a certified AP approval product, and they do not execute payment.

When is a spreadsheet tracker no longer enough?

When intake has more than one channel, when approval needs a protected audit trail, or when an approved row must create an accounting draft without retyping. That is the move from a template to a Document Intake and Approval System. Sheet protection is not that audit trail. Google says protected ranges are not a security measure.