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.