Why is the overall total sum amount different from the sum amount per debit credit?

Can you show us the workflow? Even screenshots would help

My guess is that the data either refreshed between runs, or there is another TRNDBCR value being filtered out before summing - but just guessing

JerryCooperCMA

This appears to be classic double-entry accounting data, but as Alex says, maybe the Debits and Credits are out of balance due to data refresh timing. Relevant questions: is the difference between the "K" and "D" record transaction amounts always the same (94,600) or does it change from Run to Run? Is this a real-time data source in which data could be changing dynamically while the workflow is running? Are any filters being applied which could result in partial/incomplete accounting entries?

The difference between Debit and Credit is always the same every time I run it (for that particular month). The data input is static. No filters is applied.

How Numbers Work in Designer: Decimals, Rounding T... - Alteryx Community

Then can you provide the data? Only the two columns would be needed - TRNDBCR and TRNAMNT

jrlindem

Without sample data, there can only be speculation. So, I'm not saying that the article i'm posting below is related to your issue, BUT it does go into detail around how Alteryx handles numbers and it could very well give some clues as to why the numbers can aggregate in unexpected ways....

@novalcia

What is the data type of TRNAMNT? If it's a double/float, what happens if you change it to int64?

I can't attach the data because even with only 2 columns (TRNDBCR and TRNAMNT), it's 690MB, which exceeds the allowed attachment size limit.

But here is the workflow:
Screenshot 2025-11-06 223738.png Screenshot 2025-11-06 223729.png

If I change it to int64, it still gives a difference when grouping by debit credit but the numbers are different:
Screenshot 2025-11-06 232745.png Screenshot 2025-11-06 232647.png

Are you open to providing the data if there was a way to share the large file?

Sure

Here's a Google Drive link for all: https://drive.google.com/drive/folders/1-MOWsNmIC47UFGQRkZ4iAQsXO4Nclg96?usp=sharing

the data is uploaded

I am seeing the same behavior in 2025.1.... very odd. @OllieClarke & @jrlindem & @JerryCooperCMA feel free to download it too if you want

@novalcia @alexnajm

I just ran the same workflow with AMP turned off. My Double numbers are the same:

but my int64 numbers are now different

weirdly both the double and int64 E1 numbers sum to 94,560.

Crosstab yielded closer but still different numbers as well...

Screenshot 2025-11-06 130711.png

@novalcia @alexnajm

When I run the same workflow in 2025.1 (2025.1.2.142 Patch: 2) with AMP on, my double numbers continue to be the same

But my int64 numbers are good again

Running in E1 gives me a couple of field conversion errors

but the same double numbers

and the same incorrect int64 numbers as E1 in 24.2

(both summing to 94,560)

AMP being on and int64 being the data type seems to be the right move here. As for why that's not working on your machines, I'm wondering if it's a memory thing, or the fact I'm running windows on parallels on an apple silicon mac? Not really sure to be honest.

@novalcia I'd create a support ticket if I were you, this is very weird behaviour, and I don't see any reference to it in the known issues of the release notes