soniq requested I disclose that I helped him separate the GB addresses from his payment addresses in the bitcoin-qt client, go through the books and verify people's payouts are accurate, get the software from espen running to issue dividends in espen's absence, generate the bitcoin sendmany command to issue the last dividend, and generate a balance sheet including the mining income, expenses, and payouts to members. I'm pretty confident that most members are being paid appropriately. The ones that have contacted us to look at it have been accurate for their situation.
There was one member severely overpaid because at one point soniq issued the exact same sendmany two payouts in a row... the first one had a large payout to bring him up to date and the second one had a matching payout which send him into being overpaid. There aren't any on the list that are underpaid keeping in mind that a payout isn't triggered until the amount is .01 or more.
I think a good way to look at it is to get the total paid out so far, remove soniq's 2% commissions and divide it by the number of shares: ( 1029.83732157 - 26 ) / 780 = 1.286970925. That's a rough estimate of what each share should have paid out to date. However, there are numerous reasons why this wouldn't be accurate (share price adjustments, per member hosting payment adjustments, loans). What I was surprised about is that the price paid out per share is different almost to each user and that makes calculating accuracy difficult. Someone would have to go into each user and calculate the payouts per share and determine the reason for the variance (usually one or more of the reasons above).
...That is why I created this spreadsheet https://docs.google.com/spreadsheet/ccc?key=0AtH6ASvoAExHdF9IcFh3QmQ2dEt4Zk5qT3lRUDFDTVE&usp=drive_web&pli=1#gid=24
This spreadsheet is a mess, specially the Ledger Jan 20/14.
Stop using it and make use of the much simpler one I created for new dividend payments.
I think the reason why soniq is reluctant to change this style of reporting is that it's generated by espen's software which divides up the BTC amount and spits out the bitcoin sendmany command. I think it's a little late in the game to stop using this software for calculations and reporting. It's been used several times in the past and was the replacement for using Silfax's automated disbursement software which caused some problems with members not being paid correctly...through confusion of how to use the software or an actual bug (I think it's the former). I've verified that espen's software is doing the right thing and have even made some tweaks and fixes to it. The reason why we can't just divide the mining income by the number of shares is that there are adjustments that need to be made in order to bring everyone's cumulative payouts into balance.