"//OTHER/" appended to transaction descriptions

Hello!

I have been testing uploading bank statements via the API and it seems that every transaction’s description has “//OTHER/” appended, e.g. “The original description//OTHER/$12.34” if $12.34 is the amount.

Is there a way to avoid this please?

Many thanks in advance!

Yours,
Andy Stewart

Hi Andy,

Thanks for reaching out on this. The “OTHER” is signifying the transaction type (“DEBIT”, “CREDIT” and when not available “OTHER”). This transaction type is explicit via bank feeds and OFX formats. Unfortunately, this information is not always included or consistently inferred by the amount value in CSVs available for download from banks (negative amounts are reported as CREDIT on some credit card statements for example). So in these cases we default to “OTHER”.

If you are uploading transactions via the JSON array of transactions format, that will also always default to “OTHER”.

We have enhancements on this JSON payload endpoint planned in the coming months and will announce here as we roll them out. In the meantime I would recommend using an OFX file upload with the API to fully complete the transaction data, the key “TRNTYPE” is used to set this particular attribute.

Hope that helps, and please just ask in here if there is anything I can help with.

Dave Kennedy
FreeAgent

Hi Dave,

Many thanks for explaining all that.

If a transaction were clearly signified, e.g. in a bank feed or OFX file, would each description have “//CREDIT” or “//DEBIT” appended?

I see that you cannot trust the amount’s sign (in a CSV) to tell you whether a transaction is a debit or a credit, but I don’t understand why you don’t trust the sign in a JSON upload to your API. You define what the input means so surely you can stipulate that a positive amount is a credit and a negative amount is a debit?

Thanks again,
Andy

Hi Andy,

If a transaction were clearly signified, e.g. in a bank feed or OFX file, would each description have “//CREDIT” or “//DEBIT” appended?

Yes, that is the behaviour to expect.

You define what the input means so surely you can stipulate that a positive amount is a credit and a negative amount is a debit?

I agree, and as part of the JSON endpoints enhancements we have planned we are looking to increase the fidelity of the payloads in line with OFX formats (potentially setting explicitly the transaction type to lower friction for accounts that are reported diffferently). Unfortunately, I dont have an exact ETA of those updates but recognise the opportunity for improvement.

Dave Kennedy
FreeAgent

That all makes sense. Thanks again, Dave!