make a framework for financial reporting

[chadwhitacre]

Closes #367.

Todo

• use tabs (from gratipay.com) for available years
• actually create reports (← @kaguillera's idea ;)
• make a budget budget finances#12
• filetype icons
• write "how to post financial reports"

[chadwhitacre]

I grabbed screenshots from http://uifest.com/product/file-types-icons-set because I couldn't get them to email it to me.

[chadwhitacre]

@kaguillera and I have started poking at Xero to see what reporting is going to be like. We're thinking we'll go with variants of the following three basic reports for each month:

• Account Transactions
• Balance Sheet
• Income Statement

We're planning to go through methodically, month-by-month, starting at the beginning (June, 2012). We'll triple-check that Xero is reconciled with our bank statements, and then we'll generate and post the three reports. We'll also look at generating CSV transaction logs, one for each year.

[kzisme]

Awesome job :) !m @whit537

[chadwhitacre]

:-)

[chadwhitacre]

I've taken the $2,369.86 conversion balance out for PNC, that was the last temporary one. The permanent conversion balance is $102.45 in New Alliance.

[chadwhitacre]

We could also maybe classify the $102.45 as an owner investment.

[chadwhitacre]

Here's how this is shaping up:

[chadwhitacre]

Here you go, @kaguillera. These are computed from the transactions json we downloaded under #308:

Month	Ending Balanced balance
2012-07	0.00
2012-08	537.11
2012-09	2,187.37
2012-10	5,505.24
2012-11	8,168.48
2012-12	11,341.18
2013-01	14,354.92
2013-02	18,066.02
2013-03	17,394.79
2013-04	14,588.69
2013-05	18,841.57
2013-06	30,140.24
2013-07	35,522.69
2013-08	35,739.75
2013-09	40,092.09
2013-10	49,683.12
2013-11	53,308.87
2013-12	58,563.46
2014-01	56,687.37
2014-02	61,285.69
2014-03	39,887.24
2014-04	44,002.40
2014-05	46,709.15
2014-06	50,919.15
2014-07	56,150.03
2014-08	50,036.90
2014-09	47,803.15
2014-10	49,228.90
2014-11	44,404.88
2014-12	36,368.40
2015-01	41,738.89
2015-02	47,196.30
2015-03	42,879.29
2015-04	50,191.04
2015-05	33,415.65
2015-06	32,500.70
2015-07	28,393.07
2015-10	28,389.43
2015-10	26,177.81

[kaguillera]

great...tanx

[chadwhitacre]

What we're trying to reconcile these three, month by month:

• bank/processor statements
• Xero
• our database

We're currently up against an issue where Stripe (and Braintree, once we get that far) send the net to our escrow account (Samurai and Balanced send the gross, and then withdraw their fees). We have not yet accounted for the fees associated with Stripe in Xero.

[chadwhitacre]

We're finding that we don't have a revenue account for the hard fees we collect from users to cover the payment processing fees that we're assessed. We have an expense account for the payment processing, but not for the revenue side. Thought we did but not seeing it now. I guess we'll have to set that up.

[chadwhitacre]

Alright, @kaguillera and I just worked through the problem of accounting for fees.

Payins

There are two methods of handling fees that our payin processors have employed:

1. Stripe, Braintree, Coinbase, and PayPal deposit the net into our bank account (we never see the fee in our bank account).
2. Samurai (FeeFighters) and Balanced deposit the gross into our bank account, and then withdraw their fees from the same bank account.

Here's what the transactions look like right now in Xero for the simplistic "net" case (1):

Account	D	C
Escrow - New Alliance	345.13
Escrow - Liability		345.13

In other words, we don't account for the processing fee at all!

And here's what we have currently in Xero for (2):

Account	D	C
Escrow - New Alliance	24.11
Escrow - Liability		24.11
Payment Processing	2.00
New Alliance		2.00

That is, when we manually split the New Alliance transactions between escrow and operations, we assigned payment processing to the operations side. We should go back and assign those to operations to a) better align with what actually happened, and b) fall under how Balanced did things (2) so we can have only two cases to handle instead of three.

Here's our target for (1), using Stripe as an example:

Account	D	C
Escrow - Stripe	375.24
Escrow - Liability		345.13
Processing Fee Income		30.11
Escrow - New Alliance	345.13
Escrow - Stripe		345.13
Processing Fee Expense	30.11
Escrow - Stripe		30.11

We don't have an Escrow - Stripe right now. We also don't currently have a Processing Fee Income account, and Processing Fee Expense is currently called Payment Processing.

Here is our target for (2), using Samurai and a $2.00 fee as an example:

Account	D	C
Escrow - Samurai	24.11
Escrow - Liability		22.11
Processing Fee Income		2.00
Escrow - New Alliance	24.11
Escrow - Samurai		24.11
Processing Fee Expense	2.00
Escrow - New Alliance		2.00

We have an Escrow - Balanced, but not an Escrow - Samurai.

[chadwhitacre]

Payouts

Here are the strategies our payout processors have employed:

1. Coinbase, PayPal, and TranserWise withdraw the gross from our bank account, and extract their fee on the way out.
2. Balanced batched their fees and extracted it periodically from our bank account.

Here's what we currently do for (1):

Account	D	C
Escrow - PayPal	350.33
Escrow - New Alliance		350.33
Escrow - Liability	350.33
Escrow - PayPal		350.33

I.e., we don't account for the fee at all.

Here's what we do for (2):

Account	D	C
Escrow - Balanced	2,078.87
Escrow - Liability		2,078.87

First, moving money back and forth between Escrow - New Alliance and Escrow - Balanced was asynchronous from bank payouts. Second, Balanced never actually charged us for bank payouts because we were special-cased as an early customer. So I think we're good here?

For (1), here's what we want:

Account	D	C
Escrow - PayPal	350.33
Escrow - New Alliance		350.33
Escrow - Liability	3.00
Processing Fee Income		3.00
Escrow - Liability	347.33
Processing Fee Expense	3.00
Escrow - PayPal		350.33

[chadwhitacre]

Working another example as we try to reconcile June across bank statements, Xero, and the Gratipay db ...

Date	Account	D	C
2012-06-22	Escrow - Stripe	25.29
	Escrow - Liability		20.67
	Processing Fee Income		4.62
2012-06-28	Escrow - New Alliance	20.97
	Escrow - Stripe		20.97
2012-06-28	Processing Fee Expense	4.32
	Escrow - Stripe		4.32
2012-06-28	Processing Fund	0.30
	Escrow - New Alliance		0.30

Ideally, processing fee income and expense cancel each other out. In reality, there are minor discrepancies that we need to account for. Here we're proposing a "Processing Fund" asset account where we send excess and whence we pull it back into Escrow when we have a shortfall.

[chadwhitacre]

I made a Fee Fund bank account in Xero (account number — as with all of them).

[chadwhitacre]

I've made Escrow - Samurai and Escrow - Stripe accounts. I believe we have all the accounts we need to redo June, 2012 now.

[chadwhitacre]

We have some income even after June 1, 2012 that was from IHasAMoney.com, a product of Zeta Design & Development, LLC from before Gittip (here's a lightening talk about it). We'll need to account for that.

[chadwhitacre]

Hey @tlevine, you still up for helping with this? What's your tomorrow like? @kaguillera and I are coworking together tomorrow and maybe a call would be a good way to start. Eh?

[tlevine]

Yes

Tomorrow's not good

January 4 on is good.

And it happens that I was thinking over the past few days about when to
visit Ambridge. How about the end of March or first week of April?

On Tue, Dec 22, 2015, at 06:18 PM, Chad Whitacre wrote:

Hey @tlevine, you still up for helping with this? What's your tomorrow
like? @kaguillera and I are coworking together tomorrow and maybe a call
would be a good way to start. Eh?

---

Reply to this email directly or view it on GitHub:
#390 (comment)

[chadwhitacre]

@tlevine Huzzah! Shall we move this discussion to #448? :)

[chadwhitacre]

Rebased on master. Previous head was 433e648.

[tlevine]

I had a more precise idea as to what this "framework" is.

The quick version is that I determine whatever components of Gratipay's
2015 tax filings that we presently need to determine.

Better version is that we add website features that export transaction
data from Gratipay for import into contemporary personal accounting
software (GnuCash, for example). Teams and accounts will be able to
export their own transactions. Ideally, we set it up so that Gratipay
itself can use its own team's export rather than having a special
version.

On Wed, Dec 23, 2015, at 03:01 PM, Chad Whitacre wrote:

Rebased on master. Previous head was
433e648.

---

Reply to this email directly or view it on GitHub:
#390 (comment)

[chadwhitacre]

The quick version is that I determine whatever components of Gratipay's 2015 tax filings that we presently need to determine.

I say go for it! If you want to come up with a proposal we can compare it against what @kaguillera and I have been looking at.

[tlevine]

Oh, hah, I hadn't noticed that stuff; I was just reading the emails.
This is a more ambitious version of what I'm thinking. I want to start
with the transaction report and to generate everything else based on
that. And I want to start only after I know the schemas of all the
relevant data sources that we presently have.

On Sun, Dec 27, 2015, at 12:52 PM, Chad Whitacre wrote:

The quick version is that I determine whatever components of Gratipay's 2015 tax filings that we presently need to determine.

I say go for it! If you want to come up with a proposal we can compare it
against what @kaguillera have been looking at.

---

Reply to this email directly or view it on GitHub:
#390 (comment)

[chadwhitacre]

@tlevine Schema is in sql/schema.sql. Relevant tables are exchanges (between Gratipay and other systems) and transfers (inside Gratipay).

We've been using Xero. Have you used that before?

[tlevine]

Xero is proprietary. I'll do the part before the data get into Xero.
What are you doing in Xero?

On Sun, Dec 27, 2015, at 03:50 PM, Chad Whitacre wrote:

@tlevine Schema is in
sql/schema.sql.
Relevant tables are exchanges (between Gratipay and other systems) and
transfers (inside Gratipay).

We've been using Xero. Have you used that before?

---

Reply to this email directly or view it on GitHub:
#390 (comment)

[chadwhitacre]

@tlevine Our plan has been to account for both operations and escrow in Xero, so that it's our single source of financial truth for Gratipay. The plan is to generate monthly reports from there (transactions, income/expense, balance sheet) to post on inside.gratipay.com.

[chadwhitacre]

Alright, how about this. @tlevine wants to use FOSS, and @nathanairplane wants to build an ecosystem to support platform cooperatives, which I take it would include accountants that are comfortable using FOSS, yes? @kaguillera and I are talking under #449 about whether to start from scratch in Xero now that we have a better idea of what we need to do to reconcile Gratipay's books. Now we're thinking that we should use #449 to test out a FOSS system. We're thinking http://ledger-cli.org/, because it looks nice and clean, and it's what Conservancy uses.

@bkuhn Are you still using Ledger? Do you recommend it?

@nathanairplane @bkuhn Know any accountants that are comfortable with Ledger or other FOSS tools?

[ntnsndr]

I don't know myself, but it may be worth asking on the techcoop email list. There was a conversation there recently about accounting.

https://npogroups.org/lists/info/tech-coop

[chadwhitacre]

Early returns on ledger are quite positive. Check out gratipay/finances#1. We'll write up some docs for the README over there explaining what we're doing (mostly distilling info on this and #449).

[chadwhitacre]

Thanks @nathanairplane. I searched for "accounting" in the archives and didn't turn up anything. I will do some browsing when I get a chance.

[chadwhitacre]

The framework this ticket calls for is coming together nicely on gratipay/finances#1. Let's rework the commits on this PR to make whatever doc updates are called for on Inside Gratipay once gratipay/finances#1 settles down a little more.

Ultimately we want to get caught up on past reconciliations so we can start reconciling each month going forward. We've got 42 months to reconcile, counting June, 2016 through December, 2015. If we knock out two a week it'll take six months or more to get caught up.

We also want to have our books audited or at least reviewed by our CPA (#285 #350). I think we should try to schedule something ASAP (we may already be too far into the US CPA's busy season) so we can make sure we're on the right track with gratipay/finances#1. Maybe then we can schedule our first full annual audit in 2017 after we're all caught up.

[chadwhitacre]

To: CPA
Subject: meeting to review Gratipay's books

Greetings and Happy New Year!

We've done a lot of work on Gratipay's books since the last time you and I talked, back in September. I think we've now got a pretty good system in place, and we're close to reconciling our first month—June, 2012. We're aiming to be fully caught up in Q3, after which I'd like to talk about our first audit.

Before then, though, I'd appreciate a meeting to make sure we're on the right track with how we've got the books set up. Wednesdays and Thursdays are best for me, but I can make most days work. Can you fit us in anytime soon?

[chadwhitacre]

Also, let's go ahead and start keeping books with the new system with January, 2016. That way we're not falling further behind while we play catch-up.

[chadwhitacre]

Now that we're through #350, let's bring this in for a landing. What will that take?

[chadwhitacre]

Rebased to go a quite different direction in view of our new finances repo. Previous head was da69c43.

[chadwhitacre]

Blech. This doesn't work because GitHub sets X-Frame-Options: deny. :-/

[chadwhitacre]

Maybe we need gh-pages first, as discussed in gratipay/finances#5?