Problems getting clean journal entry data out of Quickbooks online

Beginner Questions
, ,
1

Hi all,

I am new to Make.com and trying to automate some end-of-month accounting reconciliation procedures for my company. I am stuck at this last step of posting one line of a journal entry that is generated by KatanaMRP and to sync that data to one row in Google Sheets. I have been using Gemini to help me build this and created this summary below with Gemini to help me solve this problem. Thanks in advance for any help I receive!

Objective

We are syncing order data from ShipStation to Google Sheets (Audit Log) while pulling related financial values from QuickBooks Online (QBO).

Specifically, we want to populate Column F with a QBO Journal Entry amount (TotalAmt) and calculate a COGS variance in Column G ([ShipStation/Katana Cost] - [QBO TotalAmt]).

The Architecture & The Core Problem

The workflow begins with a ShipStation trigger/search, passes data through QuickBooks, and attempts to log a single row per order in Google Sheets.

However, because of how QuickBooks stores journal entries/lines, the QBO module outputs a massive volume of duplicate data packets (58 identical bundles for a single transaction). This bundle explosion causes downstream Google Sheets modules to execute 58 distinct times, flooding the spreadsheet with identical rows.

What We Tried & Why It Failed

Attempt 1: The Basic Array Aggregator Strategy

  • Setup: We placed an Array Aggregator after the QBO module to condense the 58 bundles back into 1 single array, using the formula {{get(map(19.array; "TotalAmt"); 1)}} to extract the amount into Google Sheets.

  • Why it failed: The aggregator duplicated anyway. Because the upstream QBO structure acted as independent trigger bundles rather than a single cycle loop, the aggregator executed 58 separate times (creating 58 single-item arrays) instead of aggregating 58 items into 1 array.

Attempt 2: Search Rows $\rightarrow$ Router $\rightarrow$ Update vs. Add (The Infinite Loop)

  • Setup: We completely removed the aggregator. Instead, we used a Search Rows module to look for the Order ID. We added a router with two conditional paths:

    1. If Row number EXISTS, use Update a Row to overwrite the same line 58 times.

    2. If Row number DOES NOT EXIST, use Add a Row to create it.

  • Why it failed: This triggered a severe race condition and infinite loop that ran up over 162 operations instantly. Because Make processes these multi-bundles sequentially at lightning speed, Bundle 1 didn’t find the row and triggered “Add a Row”. But before Google Sheets could physically commit that row to the database and update its index, Bundles 2, 3, and 4 had already executed their “Search Rows” module. They also found nothing, triggered “Add a Row” again, creating an exponential loop.

Current Status / Help Needed

We need a clean, operation-efficient method to enforce a strict “one bundle only” pass after the QuickBooks module fires, or a bulletproof way to pause execution so the search-before-write mechanic doesn’t experience a race condition.

Sheets 21
Sheets 211222×980 94.7 KB

QBO 14
QBO 141300×520 53.1 KB

Sheets 24
Sheets 24906×1314 80.1 KB

Sheets 20
Sheets 201286×1264 130 KB

Integration Google Sheets.blueprint.json (102.3 KB)

Make Screenshot
Make Screenshot2548×1322 261 KB

4

Hey there,

your attempt one most likely failed because you had the wrong source module set for the aggregation.

I strongly suggest not using an AI to build complex Make scenarios at this stage since all of them suck at it and mess up basic stuff.

Which module is producing the duplicates and is it always producing either one correct value or multiple duplicates of the same correct value?

5

Hi Stoyan,

Thanks for the response. I am not a developer, just a business owner trying to automate some end-of-month accounting functions :slight_smile:

The only problem I see is that I get 2 rows/entries for each side of a journal entry in QBO. I only need the one amount/row and trying to avoid duplicate entries.

Otherwise everything seems to be working fine at this stage.

Any thoughts?

Thanks

Bryan

6

Find out which module is producing the duplicates and set that as the source module for the aggregation.

7

The 58 duplicate bundles from QBO is a classic Make.com headache. The real fix here is using an Iterator with an Aggregator set to bundle order number as the grouping key before anything hits Google Sheets. That stops the race condition entirely. For teams automating financial data flows at scale, platforms like Phonexa handle structured data routing cleanly without these multi-bundle nightmares. Good luck getting this sorted!

8

My problem is I don’t have advanced skills. I need help getting this done :slight_smile:

9

Is this a friendly SMB platform? I would like to figure this out with Make as we are using it for multiple workflows.

10

Hey Bryan :waving_hand:

Let me give it a try. :slightly_smiling_face:

The problem is that your QBO Search Journal Entry module (14) outputs one bundle per line item inside each journal entry. Since your entry has 58 lines, you get 58 bundles that all trigger your downstream modules 58 times.

You may try these fix:

  1. After your QBO module (14), add an Iterator to collect all 58 bundles into one array.

  2. After the Iterator, add an Aggregator with the Iterator as its source module. This fires only once.

  3. Reconnect your Google Sheets modules to the Aggregator output instead of directly to QBO.

  4. Turn on “sequential” in your scenario settings to prevent the race condition.

The Iterator + Aggregator combo ensures everything downstream runs once instead of 58 times.

Give it a try and let us know how it goes!

-John