We break up expense payments for each property, and for the type of expense. This is to make it easier in doing accounting later to not have to re-figure out what happened and do all the splits. So for sake of argument assume $25 for lawn care x2 properties, and a $20 repair at each of x2 properties, all of which happened on the same day. We use venmo to pay this person with funds coming out of our biz checking, as four tx. The tx shows up as “Transfer to Venmo”, on the same date, with two cases of the same amount:
(for prop1): “Transfer to Venmo”, 9/1/2025, $25
(for prop1): “Transfer to Venmo”, 9/1/2025, $20
(for prop2): “Transfer to Venmo”, 9/1/2025, $25
(for prop2): “Transfer to Venmo”, 9/1/2025, $20
The Stessa duplicate rejection logic seems to not have or use a unique transaction id, instead relying on the tuple (name, date, amount) to uniquely identify transactions. In the import I only see two tx:
“Transfer to Venmo”, 9/1/2025, $25
“Transfer to Venmo”, 9/1/2025, $20
Is this caused by Stessa logic, or is this a problem with the new account linking provider? Can this be shut off, or would it cause mass duplicates to appear? I just assumed there was some unique tx number behind the scenes that was being used to prevent re-import of earlier imported txs.
This wasn’t happening before July 1, 2025, but it now happening.
What do I do now? Notice each instance and manually add new Tx for those missing? I would want the manually added tx to be annotated with the Checking account, so do I have to do a CSV import to make that happen?
At least when data import stops, it’s obvious. Here it’s not obvious and I have to check for missing txs.
Thank you,
Mike.