Hey @Cafe_Manager , I can finish this by moving the aggregation and deduplication logic fully into Make so Google Sheets only receives finalized rows that reconcile to Toast Daily Sales Summary. The key fix is to standardize the grouping logic around business date, revenue center, service window, and category, then make each run idempotent so partial or duplicate executions can’t contaminate reporting. I’d also validate the Toast source fields being used for net sales, voids, discounts, modifiers, and checks/order timing, since mismatches usually come from aggregation rules rather than the API pull itself. For Sheets, I’d replace SUMIFS-based reporting with a clean append/update structure driven by unique keys from Make. I’ve worked with API-to-Make reporting pipelines like this and can debug the current scenario without rebuilding it from scratch. If you send the existing Make scenario, sample sheet, and one Toast Sales Summary report for comparison, I can pinpoint the variance and finish the automation.
Feel free to book a meeting with me here to discuss this further.
This looks like a classic case of aggregation being handled in Sheets causing mismatches, especially with duplicate or partial runs. Moving the aggregation fully into Make should fix the consistency issue and ensure totals match Toast exactly.
Quick questions about your setup
• Are you currently grouping and aggregating data inside Make or only in Sheets
• How are you handling duplicate or partial runs right now
Happy to take a look and help you get this stable.
Hello @Cafe_Manager , welcome to make.com community, I have worked and have experience with Make.com and l will love to collaborate with you on this you can schedule a call Here and you can checkout my upwork profile Here, for my pastworks and certifications
Have sent you a DM as well. Would love to help you debug your current Toast POS and Google Sheets integration and fix it to run reliably using Make. I run an automation studio called Automation Jinn where we help companies automate their processes and increase efficiency. I am Make advanced certified with a background in computer science so quite comfortable in integrating API, Webhooks and Custom code beyond low code/no code tools. I have experience working with both SMB’s and large enterprises.
Some of my relevant work-
• For an education company, I integrated LMS with Airtable, Make, and CRM via API handling complex pagination and syncing data in real time.
• For a digital agency, I set up a smart call-routing system using Twilio and Airtable API to automate lead handling.
• For a bakery brand with a large social following, I implemented chatbots integrated with a custom CRM in Airtable and automation workflows to handle orders and FAQs saving hours of manual coordination every day.
I work more as an AI transformation partner for my clients rather than just a builder. Would love to learn about your day to day operations
I’ve dealt with Toast API’s quirks before, and I know exactly why your numbers aren’t matching. Toast’s raw item data often includes modifiers, discounts, and tax overrides that can throw off a simple Sheets SUMIFS. If you don’t account for the “Order State” or how Toast handles voids vs. returns in the raw export, the totals will never align with the Sales Summary.
I can definitely move this logic into Make so you stop fighting with spreadsheet formulas.
Here’s how I’ll fix it:
Move Logic to Make: I’ll use Make’s “Data Store” or “Array Aggregator” to group your data by Date, Revenue Center, and Time before it ever touches the Sheet.
Total Reconciliation: I’ll ensure we’re pulling the right fields (Net vs. Gross) to make sure your Food/Liquor splits match the Daily Sales Summary to the penny.
Duplicate Prevention: I’ll add an “Upsert” check (Update or Insert) using a unique ID for each day/category combo, so even if the scenario runs twice, you won’t get double data.
Time Bucketing: I’ll set up the Lunch/Dinner logic directly in Make based on the order timestamps so the “Cafe vs BYT” reporting is fully automated.
Why me?
I’m a systems-oriented developer and I’ve built “Content & Lead Factories” where data accuracy is everything. I don’t just build MVPs; I build stable, production-grade tools. I’m comfortable with complex GUID mapping and Toast’s specific API structure.
Hi. I work with Make scenarios pulling restaurant POS data into Sheets. The CATEGORY_MAP problem you describe usually traces to one of three things: GUID mismatch when an item gets re-categorized in Toast,
array vs object shape coming back from the API after a menu update, or the lookup module hitting Sheets before the map sheet is fully loaded.
I can jump on it tonight. $70 fixed for diagnose + fix + a short note explaining what broke and how to keep it stable. Pay after you see the rows landing correctly. No upfront.
If you can share a screenshot of the broken module and one row of raw Toast payload, I can usually pinpoint within 30 minutes.
