These past few days have been rough, not gonna lie. In the last update, I mentioned some shops on the new system couldn't get data for "today" — and honestly, I was freaking out a bit. Thought maybe I was going down the completely wrong path with this new approach.

Well, plot twist — it was my own damn bug in the new pipeline. My code was silently dropping webhook events from Shopify. Data on Shopify's side was perfectly fine the whole time. I was just... not catching it. You know that feeling when you're looking for your glasses and they're on your head? Yeah, that.

Fix is deployed. Webhooks are now received and processed properly. If you're on the new system, your "today" data should be flowing in as expected. This does not affect stores on the current system — everything there continues to work as before.

A bit embarrassing that it was my fault, sure. But hey — if it's my bug, I can fix it, and that's the best kind of problem to have. I'm keeping a close eye on things for the next 24 hours to make sure everything stays solid.

If you haven't joined the whitelist yet — please do! I really want you to try it out. The more stores on board, the more confident we can be before the full rollout. Hit up our Customer Support to get added.

Thanks for bearing with me. I'm genuinely happy today.

Heads up: We've noticed that for some stores with a large volume of orders, Shopify appears to be delaying the delivery of data back to us.

What this means for you: if your store processes a high number of orders, your profit data might take a bit longer than usual to show up on your dashboard. Your data is not lost — it's just arriving slower than expected from Shopify's side.

We're actively investigating this to understand the exact cause and whether there's anything we can do on our end to speed things up. We'll post another update once we have more clarity.

If you're seeing delays and it's affecting your workflow, reach out to our Customer Support team — we're keeping a close eye on this.

Quick update: the new system is now live for whitelisted stores.

If your shop is on the whitelist, you should already see accurate numbers on your dashboard. We've been monitoring closely and everything looks solid so far.

A few things to note:

This currently applies to the Dashboard only — other pages will follow soon. If something still looks off, please reach out to our Customer Support team and we'll look into it right away.

We're continuing to expand the rollout to more stores. Stay tuned.

New system is in production.

I've integrated the new revenue calculation into the existing pipeline. It works, but I'm rolling it out to a small group of shops first before expanding.

If you want in early, message CS with your Shop ID. They'll pass it to me and I'll whitelist you.

This is new code — there might be issues I haven't caught yet. If something looks off, let CS know and I'll fix it.

We are beyond excited today. You have no idea how happy I was when I saw the numbers we calculated from the API match exactly with the data exported directly from your shops. You know that feeling when you've been staring at a spreadsheet for hours, something just won't balance — and then it finally clicks and every number lines up perfectly? That's exactly how it felt.

But here's the honest part: the hard work isn't over. The next big challenge is figuring out how to integrate this new system with TrueProfit's existing pipeline. The metrics between old and new don't align cleanly, and that creates real friction.

One trade-off we're accepting: Calculation Config — the feature that let merchants customize how metrics are computed — will no longer work as before. But here's the thing: very few merchants actually used it, and in most cases, it was the very thing causing confusion in the first place. Numbers looked "wrong" because a config was silently changing how they were calculated.

We believe the right path forward is to find a smarter, unified approach to handle different business models — one that adapts intelligently and consistently, rather than relying on patchy per-shop configs that create more problems than they solve.

More updates as we make progress on the integration.

The Agreements API transition is working — and it's fast.

Yesterday we announced the decision to move to Shopify's Agreements API for sales metrics. Today, we've made significant progress on that migration.

We've successfully built a new sync pipeline on top of the Agreements API with a redesigned database layer. The results so far are very promising — even shops with extremely large datasets (hundreds of thousands of orders) now query in seconds, where the old system would struggle or time out.

The key difference: instead of reconstructing sales figures from dozens of fragmented fields and complex formulas, the Agreements API gives us Shopify's own calculated values directly. This eliminates the entire class of edge cases that has been causing discrepancies — tax-inclusive rounding, partial refund adjustments, late order modifications, and more.

We're continuing to validate across more shops before rolling out broadly. More updates soon.

Moving to the Agreements API for sales metrics.

I have decided to completely transition to using the Agreements API to calculate sales metrics, rather than relying on our own complex formulas. The Agreements API provides much more accurate and reliable data.

I want to send my sincerest apologies to our customers. I am deeply grateful for your patience during this time.

I also want to express my gratitude to my teammates on the Customer Success team, and to my fellow engineers sitting right beside me fixing bugs. It's really exhausting, isn't it?

Shopify silently changed how refund_discrepancy adjustments work.

During our investigation, we discovered that Shopify changed their API behavior on Feb 26, 2026: zero-refund and under-refund order_adjustments are no longer created for many stores. This means the discrepancy data we relied on from Shopify webhook payloads is now incomplete or missing entirely.

We are still assessing the full impact of this change across all affected shops. This is a platform-level change on Shopify's side and requires us to rethink how we calculate refund discrepancies independently.

→ Shopify API behavior changed on Feb 26, 2026. We are tracking this platform-level change.

Honest update on where we stand.

Despite multiple fixes we've shipped over the past two weeks, the revenue accuracy issue has proven to be far more complex than we initially expected. The calculation formula involves many interacting components — tax rules, refund attribution, discount allocation, cross-month adjustments — and each fix has uncovered new edge cases underneath.

We've made the decision to split into two parallel teams:

Team 1 — Immediate fixes: Continuing to patch and correct numbers for affected shops as quickly as possible.
Team 2 — Long-term solution: Designing a fundamentally new approach to revenue calculation that eliminates these compounding issues at their root.

During this period, some merchants may see discrepancies of a few hundred dollars, or a small percentage difference in their revenue numbers. We know this impacts your business decisions and we are deeply sorry.

Several members of our team have been working through the night, every night, since this issue was first discovered. We want you to know: we are giving this everything we have.

We sincerely apologize for the disruption. We won't stop until this is fully resolved.

Fixed: Returns over-reported for some shops due to stale data in order records.

We found that some order records in our database carried leftover refund values from a legacy sync process. These values were no longer being written by our current pipeline, but they were never cleaned up either — so they silently inflated the Returns metric for affected shops.

We've deployed a code fix that explicitly resets refund fields on order records during every sync, preventing this from happening again. We've also updated our investigation tooling to automatically detect and correct this issue across shops.

Transparency update on what we've learned so far.

As we've been digging deeper into the revenue calculation pipeline, we've uncovered a significant amount of hidden logic embedded across our system — particularly around how tax, returns, and refunds are computed. Many of these calculations have implicit rules and edge cases that were never clearly documented or aligned with product specifications.

For example: tax-inclusive vs tax-exclusive pricing, partial refund adjustments, cross-month return attribution, and order-level vs line-item-level discount allocation each have their own quirks that interact in non-obvious ways. Some of this logic was written years ago to handle specific Shopify behaviors, but the reasoning behind it was never captured — making it fragile and hard to verify.

We're planning to work closely with our product team to review and refine these calculation rules from the ground up — ensuring every formula is clearly defined, well-documented, and testable. This won't happen overnight, but it's the right investment to prevent these kinds of issues from recurring.

In the meantime, we're continuing to fix the immediate accuracy issues and verify numbers shop by shop.

Working on the next root cause — the pending refund discrepancy.

When a merchant issues a refund, Shopify sometimes creates a PENDING_REFUND_DISCREPANCY adjustment after the refund webhook fires. Our system only captured data at webhook time, so this late adjustment was missed — causing return numbers to be slightly off for affected orders.

The fix: instead of relying solely on webhook timing, we're integrating the Shopify Agreements API to fetch the complete, final adjustment data directly from Shopify. This ensures we always have the full picture, regardless of when Shopify finalizes the refund.

We've already verified our revenue formula across 9,281+ orders on 5 different shops with exact parity against Shopify's own reports. This fix will close another significant gap.

Major milestone — we've deployed 13 production releases across our order processing and reporting services. All identified code-level bugs are now fixed.

We also built a comprehensive 4-source comparison tool that cross-references your data across Shopify GraphQL API, ShopifyQL reports, our database, and the TrueProfit dashboard. This lets us verify accuracy down to the cent for any shop.

Here's what we've fixed so far:

Fixed Ghost/phantom records — stale data snapshots created duplicate line items that inflated gross sales by $5K-$20K on affected shops
Fixed Missing refund timestamps — refund records lacked the refund_at field, making refunds invisible in date-based reports
Fixed Duplicate report entries — a code path was writing two sets of base records for the same order, doubling revenue for those entries
Fixed Discount allocation gaps — order-level discount codes weren't being properly distributed to individual line items
Fixed Order sync race condition — database writes were completing after message dispatch, causing downstream reads of stale data

We're now working on historical data repair and continuing to investigate for any additional issues. We're not stopping until every number matches.

Deployed two critical fixes today:

Refund timestamp backfill — We discovered that refund records in our sales reports were missing the refund_at timestamp entirely. When your account uses date-based refund attribution, our calculator tried to match refunds by this field and found nothing — making those refunds completely invisible in your reports. We've fixed the code and backfilled 357,000 historical refund records from the source data.

Duplicate record cleanup — A code path in our report generator was writing records with an empty event field. This created a second set of base records for the same order — effectively doubling the revenue for affected orders. Fixed the filter logic and cleaned up the duplicates.

Two more fixes shipped:

Ghost/phantom records — This was the biggest contributor to revenue overstatement. When orders are edited after purchase (e.g., items removed or quantities changed), our old sync logic kept the original line items as "ghost" records. These phantom entries inflated gross sales by $5K-$20K per affected shop. We now cross-reference every record against the live Shopify API and remove entries for line items that no longer exist.

Discount allocation — Some orders had discount codes applied at the order level, but the discount amounts weren't being distributed to individual line items in our reports. This made discounts appear lower than they actually were. Added a proportional fallback calculation that correctly allocates discounts even when the raw line-item data is incomplete.

First fix deployed: order sync race condition.

We found that when a new order comes in from Shopify, our system was dispatching the processing message to the queue before the database write completed. This meant our reporting service sometimes read stale or missing data. We reordered the operations so the database write always finishes first — ensuring downstream services always work with fresh, complete data.

Full investigation launched. After analyzing merchant reports, we've confirmed that a code change deployed on March 20 disrupted our sync and sales report pipeline. An initial fix attempt made things worse — it introduced data inaccuracies and further broke the synchronization flow.

We're now building a comprehensive comparison tool that cross-references data across 4 sources — Shopify GraphQL API, ShopifyQL analytics, our database, and the TrueProfit API — to identify every single discrepancy and its root cause.

Your Shopify store data is completely safe. No data has been lost or corrupted — this is entirely within our reporting pipeline. We'll post detailed updates here as we fix each issue.

Incident started. A code change to our sales report pipeline unintentionally disrupted the sync and calculation process, causing data to stop updating for some merchants. We attempted an immediate fix, but it was done incorrectly — leading to data inaccuracies and further disruption to the synchronization flow.

We're aware of the issue and working to understand the full scope of impact.