This project brings employee expense submissions into one consistent process. Employees submit their details through a form, the workflow checks the amount and searches for matching expense records, and Google Sheets stores the submission with its review status. Employees receive confirmation that their expense has been recorded, while a designated reviewer receives an alert when a submission requires attention.
The result is a practical starting point for a business that wants to reduce manual intake work and make expense exceptions easier to identify. The workflow supports the administrative steps leading up to a review decision. A person remains responsible for determining whether the expense is valid, approving reimbursement, and arranging payment.
1. Business brief
Who this is designed for
The intended users are small businesses, agencies, and operations or finance teams that collect employee expenses without a dedicated expense-management system. These teams may already use Google Workspace and maintain a spreadsheet as their shared record of submissions. The person responsible for reviewing expenses might be a business owner, an operations manager, or a finance administrator.
For this type of business, a useful first improvement is a consistent way to capture expense information, record it, and draw attention to entries that need a closer look. This project demonstrates that process using familiar tools.
What slows the process down
When expenses arrive through separate emails or messages, someone has to collect the relevant details and enter them into a spreadsheet. That same person may then check the amount, look through previous entries for a possible repeat, acknowledge receipt, and notify the appropriate reviewer.
These repeated steps take attention away from the review itself. Inconsistent submissions also make the record harder to use: details may be scattered across conversations, employees may be unsure whether their submission was received, and reviewers may have to search for the reason an expense was flagged.
What successful operation looks like
For each validly completed form submission, the workflow should preserve the submitted details, apply the configured review rules, and create a spreadsheet record with an identifiable submission ID. It should then acknowledge the submission to the employee and alert the reviewer when the status requires attention.
Success is assessed through observable behavior: the correct record is saved, the correct status and reason are assigned, and the expected notifications arrive. The project has not yet established a measured reduction in processing costs or staff time, so those benefits are presented as intended outcomes rather than proven savings.
2. The working workflow
Submission and data preparation
The employee completes a form containing five required fields: employee email, expense date, vendor, amount, and description. The form states that amounts must be in USD. The workflow adds the currency, submission timestamp, an execution-based submission ID, and initial review fields.
This gives each record a consistent structure before it reaches the spreadsheet. The submission ID helps connect the saved record with the emails generated during that execution. It identifies a workflow run; it is not a guarantee that a repeated submission will be prevented.
Possible-duplicate detection
Before adding a row, the workflow searches the spreadsheet for a matching duplicate key. That key combines the employee email, expense date, vendor, amount formatted to two decimal places, and currency. Email and vendor values are trimmed and converted to lowercase for matching, reducing differences caused by capitalization or surrounding spaces.
A match becomes a possible-duplicate warning. The submission is still recorded so a reviewer can determine whether it represents a repeated claim or a legitimate expense with identical details. This distinction matters: two matching records are evidence for review, not proof that a claim is invalid.
Amount checks and review routing
The demonstration uses a USD 500 review threshold. The rules are evaluated in order, with each expense following one amount branch. Duplicate findings are then applied to the result.
| Submission condition | Final status | Explanation recorded | Reviewer notified? |
|---|---|---|---|
| Amount is zero or negative | Needs Correction | Amount must be greater than zero | Yes |
| Positive amount up to and including USD 500, with no match | Pending Review | No exception reason | No |
| Amount exceeds USD 500 | Needs Review | Amount exceeds the review threshold | Yes |
| Positive amount matches a recorded expense | Needs Review | Possible duplicate identified | Yes |
| Invalid amount also matches a recorded expense | Needs Correction | Both the amount issue and duplicate warning | Yes |
The threshold is a sample business rule that would need to be agreed with a client. Pending Review means the submission is waiting for normal review; it does not mean the workflow has approved the expense.
Recording and communication
Google Sheets stores the submission ID, employee email, expense date, vendor, amount, currency, description, submission timestamp, review status, review reason, and duplicate key. These fields give the reviewer the submitted details and the reason for any exception in the same record.
After the row is saved, Gmail sends an employee receipt containing the expense details and its status. A separate condition checks whether the status is Needs Review or Needs Correction. If either condition is true, Gmail sends an alert to the configured reviewer.
The employee receipt explicitly confirms receipt rather than reimbursement approval. The reviewer alert includes the information needed to locate the submission and understand why it needs attention.
What is included in the demonstrated scope
The working project consists of 13 connected n8n nodes, a Google Sheets record structure, amount and duplicate rules, employee receipts, and reviewer alerts. A sanitized workflow template is available for reuse, along with setup documentation. Connecting that template to another business requires its own credentials, spreadsheet selection, reviewer address, policy choices, and acceptance tests.
3. Test evidence and verification
Testing focused on whether the workflow makes the correct decision and produces the expected business outputs. The following results come from screenshots and builder-reported tests of the original local workflow. They are not an independent production audit or a load test.
| Scenario | Expected behavior | Evidence collected |
|---|---|---|
| Fresh USD 85 submission | Record the expense as Pending Review, leave the exception reason empty, and send an employee receipt | Builder confirmed the saved row, status, reason, and email |
| Zero-amount submission | Record Needs Correction with an amount-validation reason | Workflow and spreadsheet screenshots showed the correction path; the builder subsequently confirmed the receipt and reviewer alert |
| Exactly USD 500 | Keep the expense in Pending Review when no duplicate is found | Spreadsheet screenshot showed the expected boundary result |
| USD 500.01 | Mark Needs Review with the threshold reason | Spreadsheet screenshot showed the expected status and explanation |
| Repeat a USD 75 expense | Record the first submission normally; flag the second as a possible duplicate | Spreadsheet screenshot showed the two submission IDs, matching keys, and changed status |
| Fresh USD 650 submission | Save the record and send both an employee receipt and reviewer alert | Builder confirmed the new row and both emails |
| Pending Review at the notification condition | Do not route the item to the reviewer alert | IF-node screenshot showed one item in the false branch |
Evidence that remains to be collected
A missing-required-field test has been specified but not documented. It should show that leaving Vendor blank prevents form submission and that no new record or notification is produced. This would verify the visible form's required-field behavior, not comprehensive validation of every possible incoming payload.
Integration-failure tests also remain outstanding. A controlled test should establish what happens when Google Sheets is unavailable and what happens when Gmail fails after a row has already been saved. The latter is especially relevant because data recording and email delivery are separate actions: an email failure does not undo an existing spreadsheet row.
The sanitized export was checked for valid JSON structure, retained connections, and removal of personal connection details. It has not been imported and executed in a separate n8n environment. The demonstrated functional results therefore apply to the original configured workflow.
Demonstration plan · Recording not yet produced
4. Short demonstration plan
The demonstration should show what a business user submits, what the automation does, and what the employee and reviewer receive. A recording of approximately two to three minutes can communicate this without inspecting every expression or node setting.
Opening: establish the problem
Start with the complete workflow on screen. Explain that the project addresses repetitive expense intake: collecting information, entering records, checking for exceptions, and sending acknowledgments. Introduce the form, spreadsheet, and two notification paths as the parts the business interacts with.
Normal submission: show the everyday experience
Submit a fresh small expense using a controlled email account. Show the workflow execution, then the new spreadsheet row with Pending Review and the corresponding receipt. Point out that the record and email share a submission ID, making the result easy to trace.
Exception submission: show the reviewer handoff
Submit a new expense above the demo threshold. Show Needs Review in the spreadsheet, the reason attached to the record, and the reviewer alert. Explain that the automation highlights the exception while leaving the decision to the reviewer.
Duplicate submission: show the additional check
Repeat the details of the small expense. Show that the second submission is recorded with a possible-duplicate reason. Explain that the workflow preserves the submission for investigation rather than silently discarding it.
Closing: explain the scope
Finish by summarizing the delivered process: structured intake, consistent recording, rule-based checks, and notifications. State that approval, reimbursement, and accounting entries are outside this version. Use demo records and hide personal details in the recording. The recording has not yet been produced.
5. Client-facing case study
The challenge
A business using messages and spreadsheets to manage expense submissions needs a reliable way to collect the same information every time and identify entries requiring additional attention. Manual copying and follow-up add administrative work before the actual review can begin.
The solution
I built an n8n workflow connecting a structured expense form with Google Sheets and Gmail. The workflow prepares submission data, checks amounts against a sample review policy, searches for matching expenses, and records the outcome. It then sends a receipt to the employee and an exception alert to the reviewer when appropriate.
The design keeps the review status and its reason alongside the expense details. It also separates employee communication from reviewer communication, so each recipient receives information relevant to their role.
Demonstrated results
The original local workflow successfully handled the documented normal, boundary, zero-amount, high-amount, and duplicate scenarios. Tests also confirmed employee receipts and reviewer alerts using controlled accounts. The implementation contains 13 nodes and uses a single spreadsheet as its submission register.
These results demonstrate functional behavior. Processing duration, staff time saved, financial savings, and production delivery rates have not been measured. The project is presented as an independently built portfolio demonstration, not a deployed client engagement.
Integration responsibilities
| Component | Role in the process |
|---|---|
| n8n Form Trigger | Collect the employee's expense details |
| n8n expressions and routing nodes | Prepare fields, evaluate rules, preserve submission data, and decide which notifications are needed |
| Google Sheets | Search existing duplicate keys and store the submission register |
| Gmail | Send employee receipts and reviewer alerts |
Limitations a client should understand
The workflow is designed for one expense per form execution. The form does not authenticate an employee's identity, and this version does not validate expense dates against a company policy or collect receipt attachments.
Duplicate detection is a lookup-based warning system. Existing records need populated duplicate keys, legitimate identical expenses can be flagged, and simultaneous submissions can both pass the lookup before either is saved. Rerunning an append can also add another row. The current design does not provide atomic duplicate prevention or guaranteed exactly-once processing.
There is no dedicated recovery or email-delivery tracking process. If a downstream email action fails, a saved expense may remain without its expected notification. The original export was inactive when reviewed; successful manual tests do not establish continuous operation. Hosting and operational arrangements would need to be confirmed before use as an ongoing business service.
What would be agreed before a client implementation
A client implementation would begin by confirming the expense policy, required fields, authorized users, reviewer address, expected submission volume, and hosting arrangements. The spreadsheet and Google credentials would be configured for the client's environment, followed by tests of normal cases, exceptions, and service failures. Any additional approval process, receipt storage, reporting, or accounting integration would be scoped separately.
How measurable results would be established
To report processing speed, record execution durations for a defined set of successful submissions and state the sample size and median. To report administrative time saved, separately time the equivalent manual work using comparable examples. Workflow execution time and human effort are different measures and should not be treated as interchangeable.
Until those measurements exist, the defensible outcome is that the workflow automates the demonstrated intake, checking, recording, and notification steps. No percentage improvement or monetary benefit is claimed.
Explore the review rules
Local illustration only: this does not execute n8n, save a record, or send email.
Further reading: Expense Report Automation with n8n: Design the Review Process First — a practical guide to intake fields, validation rules, duplicate checks, and review queues.