This is a requirement being imposed upon all treasuries. As I pointed out in my presentation to the EC, the vast majority of treasuries do not have the complexity of IEEE 802 LMSC; IEEE 802.11/15 may be the closest.
My presentation also pointed out what other treasuries may be doing to avoid the very detailed bank transactions we get as credit card transactions are deposited directly on a daily basis. Other groups contract with meeting organizers that handle all registrations and credit card transactions internally, and then interact with the group treasury with just two transactions per meeting: initial deposit, and final reckoning. IEEE 802.11/15 has this situation when they use Arinix, but not for the rest of their meetings.
As far as the reporting tool (NetSuite) is concerned, using it manually would meet the reporting requirements that IEEE mandates. However, using it manually imposes the extreme overhead upon IEEE 802 LMSC (basically, at this point, me) that we find ourselves in. IEEE has tried to alleviate some of the overhead, but it turns out the tool presented to us results in entries that do not meet the requirements of a different section of IEEE, and ended up not alleviating much of the overhead anyway.
Ben, you pointed out four options. I would point out that Option 2 may feel good in the short term, but in my experience does not result in any help from IEEE. The situation we find ourselves in is a result of many interest groups having their own requirements irregardless of how they may interact with requirements from any other interest groups, and I am left stuck attempting to navigate in the intersection of all the requirements. The interest groups simply do not care about anything except that their own requirements will be met. And, they have no incentive to get together and jointly work something out, or even think about the effects of the interacting requirements.