The challenge
A heritage hospitality and restoration company running multiple active sites was processing vendor invoices manually. Invoices arrived in every format: clean PDFs from established contractors or phone-camera photos of handwritten bills. Each one had to be opened, read, manually keyed into a tracking sheet, and routed for approval.
Different people extracted different fields in different formats. Approval happened informally over chat. There was no point where a malformed or incomplete invoice got caught before it entered the books, and for a finance function where a vendor billing at 93% project completionActual case stat: a vendor billed at 93% completion but had only been paid for 49% but paid for only 49% of it is real leakage, that intake gap was itself a risk.
Why off-the-shelf wasn't enough
Generic invoice-extraction tools assume one input shape: a clean, machine-readable document. That assumption breaks the moment a site engineer photographs a handwritten receipt. A text-based PDF has a structured data layer, the job is extraction. A photographed note has no text layer, the job is visual interpretation under uncertainty, requiring a vision-capable model, not a parser.
Treating both the same way over-engineers the easy case or under-serves the hard one. The architecture had to branch on input type at the first decision point.
The solution
A single automated pipeline built using n8n workflow takes over from the moment an invoice email lands.
A Gmail trigger watches for incoming invoice emails. Each attachment is archived to Google Drive immediately, then a routing check determines: structured PDF, or image?
PDFs → text extraction + AI agent constrained by a structured output parserForces the model to return data conforming to an exact schema, consistent field names, consistent types, every time, ensuring consistent field names and types. Images → vision-capable LLM chain with prompt engineering tuned to handwritten and photographed formats.
Both paths run a check before anything is written. Failure means a human-readable alert email flagging exactly what went wrong, not a quiet data quality problem surfacing three weeks later during reconciliation.
Data that passes validation gets split into line items, converted to an Excel register, uploaded to Drive, and routed for approval via "Send and Wait for Response" email. Nothing reaches the books without a person confirming it.
Design decisions that mattered
Match the extraction method to the actual input quality, not to a uniform AI approach. Splitting the paths lets each use the right tool for its actual problem.
Build to fail loud. Early versions had no validation gate after extraction, bad data would have flowed straight into the register with no one aware. Adding explicit null and format checks tied to automatic alert emails means a failure produces a notification, not a data quality time-bomb.
Keep humans in the loop at the points that matter. For a process tied directly to vendor payments, a human confirmation step isn't a gap in automation, it's the control point that makes the automation trustworthy enough to actually use.
The challenge
A finance analyst at a multi-property hotel group was spending three hours every morning running the same routine: log into NetSuite, pull each report, copy the data into a master Excel file, and email it out to 12 department heads. By the time it landed in inboxes, the data was already four hours old, and the analyst's morning was gone.
The finance lead flagged it as a real cost: a skilled analyst burning 15 hours a week on work a scheduled job should do. The obvious fix was NetSuite's SuiteAnalytics Connect add-on, which would allow direct live queries into the Excel dashboard. The CFO wouldn't approve it, the add-on licence ran to several thousand dollars a year for a capability the team needed for one use case. The team was stuck between wasting analyst time and making decisions on stale data.
The solution
A zero-cost automation connecting NetSuite directly to their existing Excel MIS report, using only Microsoft 365 tools they already owned.
NetSuite configured to email four daily report snapshots to a dedicated mailbox on a fixed schedule. No new licences, no new integrations, just an existing email feature used deliberately.
A Power Automate flow detects these emails, extracts the data, and overwrites the old file in SharePoint, without breaking a single existing Excel formula or pivot table.
The Finance team continues to use the exact same Excel dashboard they've always used. The file replacement is invisible. They open SharePoint and see fresh numbers.
Why this approach
The constraint wasn't technical, it was political and budgetary. Any solution requiring new licences, new tools, or changes to how the Finance team worked was dead on arrival. The brief was: deliver live data, using only what's already paid for, without touching the dashboard the team knows.
That constraint turned out to be a feature. By routing through Microsoft's native ecosystem rather than adding a middleware layer, the solution has fewer dependencies, fewer points of failure, and no vendor risk if the $5k ODBC provider changes pricing.
The ROI math was simple: the first week reclaimed enough finance lead hours to justify the engagement. Over 12 months, the saved administrative time represents over $12,000 in reclaimed salary cost, not counting the value of decisions made on hours-old data rather than days-old.
Stack
"You don't need expensive middleware to get live ERP data into Excel."
Engagement summary, Case 02
The challenge
A US-based independent restaurant had redesigned their menu but hadn't tracked when the change went live. They wanted to know whether it had affected sales, and if multiple versions existed, which one performed best. No A/B test, no logged rollout date, just sales history and a vague sense that something had shifted.
This is a common problem for operations-heavy businesses: the decision already happened, the data trail is incomplete, and the business owner is left asking what happened after the fact rather than designing for it in advance.
Methodology
We treated this as a two-part problem: first find when something changed, using only the sales data, without assumptions, then attach meaning to that date by cross-referencing available evidence.
Rather than picking an arbitrary "before and after" window, we ran statistical change point detection (Pelt algorithmPruned Exact Linear Time, a standard method for finding where a time series' underlying behaviour structurally shifts, without needing a known date via Python's ruptures library) across the full sales history. A 7-day rolling average was applied first to remove day-of-week noise, restaurant sales naturally spike on weekends regardless of menu design.
Once the breakpoint was identified, average daily and weekly sales before and after were computed, expressed as a percentage lift and a cumulative revenue figure. Where the data showed more than one structural shift, each window was treated as its own "design era" and ranked independently, rather than assuming only one change occurred.
Sales data gives you a date, not a cause. To connect the detected change point to an actual design decision, we cross-referenced the breakpoint date against Wayback Machine snapshots, Yelp and Google Maps customer photos, and design-tool version history, confirming what the menu actually looked like during each detected window, rather than relying on memory or assumption.
Before attributing any sales shift to the menu redesign, we checked the same window against pricing changes, seasonal effects, and marketing activity. A sales lift that coincides with a holiday season or a new delivery-platform promotion is not evidence of a successful redesign, separating those out is part of the deliverable, not an afterthought.
Why this matters beyond menus
The underlying capability isn't about menus. It's about taking a messy, undocumented operational change and reconstructing both when it happened and what effect it had, using whatever data trail already exists, rather than requiring perfect record-keeping going forward.
The same method applies to pricing changes, staffing changes, vendor switches, or any operational decision made without instrumenting it at the time. The instinct is the same as in Fynsignal's automation work: the goal isn't just clean dashboards, it's making decisions and their consequences traceable, even retroactively.
The challenge
The client ran procurement across multiple countries, with approvers at every level, Supervisors, Function Heads, Department Heads, Finance, sitting in different geographies and time zones. Every vendor bill, whether raised directly or converted from a Purchase Order, needed the right sign-offs based on the amount, the creator's role, and the business unit.
None of this was enforced in any system. Approvals happened over email threads. A bill landed in someone's inbox in Singapore, sat over a long weekend, got forwarded to the wrong person in London, and arrived with the Finance team a week later with no trace of who had seen it or when. The finance lead described it plainly: chasing approvals was eating more time than the actual payments work.
The solution
We built a NetSuite SuiteFlow workflow, the Vendor Bill Approval Workflow (Global), that enforces a dynamic, multi-level approval chain on every vendor bill creation or update. The path a bill takes depends on its amount, whether a PO exists, and who created it.
Triggered on create or update of any Vendor Bill.
The bill creator's designated approver reviews first, then routes to the Country Head based on subsidiary or location, ensuring the right country's authority is always in the loop, not a blanket global approver.
Triggered conditionally by amount threshold. Bills crossing defined values traverse these levels. Lower-value bills skip levels entirely, senior approval time is spent where it genuinely matters.
Final Finance review, verifies GL coding, tax mapping, and PO matching before the bill is approved and available for payment.
Any approver at any stage can reject. The workflow routes through a mandatory Rejection Reason step, storing the reason permanently on the bill record, no more context lost in email threads.
Design decisions that mattered
Email notifications at the moment of routing, not as a reminder. Each approver gets an automated email the instant the bill reaches their stage, with a direct link to the record. An approver in Dubai doesn't need to be chased, they see it as soon as it's their turn. This is the single biggest reason the approval cycle dropped from a week to under 24 hours.
Rejection captures the reason, not just the decision. Early approval workflows typically stop at a reject button. This one routes through a Rejection Reason step, the approver must log why before the bill is marked rejected. That reason sits on the Vendor Bill record permanently.
Exclusions built in at the condition level. Recurring bills and Europe Portfolio bills are excluded by condition, preventing double-workflow conflicts without requiring manual intervention.
Before vs after