Dlocal has proved challenging when pushing through to Intacct because of the vagaries of it's reporting combined with the way we handle dlocal in Intacct

The way it works when we push to Intacct is that we get the figure for what the transactions add up to from the payment gateway along with a list of the transactions that make up this total. We check that the total of the list of transactions adds up to the provided total as our first verification step. This protects us from from partial downloads (which is more of a risk with sftp csvs that with api json retrievals as an incomplete file can present as valid) and is part of a sequence of validations we do.

Finance has 2 different ways of tracking the money coming in via the processors

1. as an account in Intacct - paypal - presumably there is a feed in Intacct displaying all the ins & outs - in either case they are reconciled based on the account movements within their account rather than on what is paid out. We create a batch/journal based on daily balance movement
2. based on payouts to another account - braintree, adyen, trustly - in these case we create a batch/journal that reflects the payouts

In the case of dlocal the way finance is set up is like PayPal but we don't get accurate information from dlocal about daily balance movement. We do get it about settlement/ payouts but it's not clear we can work with this

The reports dlocal offers are

1. payins report (Daily Payins - Cross-border Model) - also called cleared transactions - e.g 20260417000001_Wikimedia_648_Cleared.csv

2. settlement report - e.g Wikimedia_cross_border_report_20260131_074608

The payins report is probably closer to our model as it shows balance movement. However there are 2 issues with the report we receive via SFTP - which perhaps dlocal can help with

1. the header often but not always adds up to the sum of the transactions in the report - eg. this image is from 20260419000001_Wikimedia_648_Cleared.csv - in this case the sum of the transactions in the report is 563.88

2. the report we are getting via the SFTP does not have the DLOCAL_TRANSACTION_ID column

Note that there is a payins report configured via the UI that does have the DLOCAL_TRANSACTION_ID but we don't see this in the SFTP and this report does not have the header row

If we are unable to get the daily cleared balance movement from dlocal our workaround options would seem to be either

1. use the settled report. We tried to make this work better by settling more often but this does not seem to be making the account easier to reconcile. We could look instead at settling ONLY ONCE A MONTH - on the 1st of the month. We would have a single transaction for which we would push up a single journal - I will have to check with Julie if this can work for her. Bonus - this would reduce transfer fees which turn out to be remarkably high

2. use the cleared/payins report we are getting, ignore the header and calculate the amount based on adding up the rows in the csv. This means our ability to detect an issue early is compromised and reduces the reliability. We would not be able to detect partial downloads

Refs
https://docs.dlocal.com/docs/reporting-payins
https://wikitech.wikimedia.org/wiki/Fundraising/Data_and_flow/Audits

Note that gravy says they use the payins report but everything else about their documentation describes the settlement report so pushing Gr4vy to make their report work/be available would not solve anything (it would effectively have the disadvantages from both workarounds 1 & 2)