Thank you for your thoughtful reply. I was afraid that it might be a topic that didn't draw much interest but I'm glad I did get some discussion.

I note that your response is almost the opposite of mine!

I think there are some key reasons why and central to this is the diverse usage of CiviCRM.

The first big difference between our approaches is the assumption about where payment data comes from. I have to admit I hadn't given any thought until after I posted this blog as to how to deal with cash and cheque payments. The reason is that about 50% of the payments we receive are credit card payments and the other 50% are payments made directly into our bank account. I guess prevalent payment methods vary a bit by country.

Secondly, I note that you refer to donations. I don't deal much with donations. I generally deal with event registrations and when people register and don't pay we do follow up - either until we determine we should cancel the registration or until they pay. About 20% of our revenue comes out of this follow up (ie. people who attend but don't get around to paying) which is why we do a lot of matching and comparing and reporting to be sure we have matched the payments correctly.

The third area, however, doesn't relate to how we use CiviCRM. It relates to what we expect from an accounting package - and specifically how payment information gets into it. I'm wondering if you can clarify your experience because in all the packages I have given serious consideration to the payment data comes directly from the bank accounts (either by automated download or manual download followed by an upload). Hence, the idea of uploading payment records into an accounting package just seems wrong to me. I'm wondering if you could clarify.

(If using the Xero / Paypal combo then the paypal payments are downloaded in the same way and it is effectively another bank account)