Bug in .csv file statement imports

When importing .csv-formatted bank statements, Manager has the ability to split single rows of the .csv file into two lines, separating gross amount of the transaction from fees that may have been deducted. This is useful, for example, when importing PayPal statements. But there is apparently a bug in some of the logic applied when the transaction is a payment rather than a receipt.

Ignoring all the many fields a PayPal (or other institution) download may contain, Manager pays attention to only certain columns. A .csv file containing a receipt from which a 2% fee has been deducted and a withdrawal (transfer) to a bank account to which a similar 2% fee has been added would be represented as below:

In both cases, Gross is the amount the financial institution pays or receives. Fee is the service charge applied, which is always an expense to the account holder. And Net is the amount posted to the target account. In the case of a receipt, the institution receives the gross amount, deducts the fee, and posts the net to the accountholder’s balance. In the case of a payment, however, the fee is added to the net amount to the recipient and the institution sees the sum of the two.

Apparently, there is logic within Manager that can properly recognize the payment and its fee. This will be imported as a receipt and broken into two lines for Gross amount and Fee. If bank rules are defined searching for “Gross amount |” and “Fee |”, both line items will be posted to their respective assigned accounts. There is also logic to confirm that Gross + Fee = Net. Otherwise, the net amount is posted without splitting the transaction. So far, so good.

For payments with fees added, the logic breaks down. Manager apparently imposes the same confirmation test, expecting Gross + Fee to equal Net. But when the transaction is outgoing, the test needs to be whether Net + Fee = Gross.

The bug can be confirmed by changing the .csv file as follows:

When importing this version of the .csv file, all transactions go through, but the payment form is wrong:

In this case, the payee should have received a Net amount of 100; the institution should receive the fee of 2, and the Total should be 102. In other words, things should be reversed on the payment form, like this:

Importing CSV from PayPal has been undocumented feature. Since it’s non-standard and PayPal appears to support QIF now, I consider this feature to be obsolete.

Have a look if you can download QIF file from PayPal and whether transactions are imported correctly.

I have two problems trying to confirm this for you:

  1. I don’t know what a *.qif file looks like from PayPal for all transaction types. In other words, I don’t know how they label the various split transactions because my account doesn’t include all types. If I knew that, I could edit the *.qif file with a text editor to test the import functionality.

  2. PayPal only exports *.qif files for USD-denominated accounts.

You are right. Since Paypal only allows to export QIF for USD accounts only, CSV support needs to be retained.

The latest version (17.7.88) fixes this issue.