So if this is such a great approach to managing financial data, why does almost everyone in the real world use QuickBooks? For small businesses, in particular, most accountants will look at you like you have two heads if you suggest managing your accounts with anything else.
And why am I writing so many custom bits of code to both extract transactions and convert them to PTA formats and then spit them back out in HTML or \(\LaTeX\)? Why can't other people reuse all of that work? If I write an exporter that can automatically pop out a 1065 and K-1s (a US Federal Tax form that is very common for partnerships and most LLCs), why can't everyone else who uses a PTA system benefit from that as well?
There are two big issues here:
- Integrations with other systems
- Identifying "Accounts" more specifically
For example, we use Stripe as our online payment processor. Consider that every time we make an online sale, our Stripe system records a transaction that includes a datestamp, customer, payment method, amount, etc., etc. We then have a script that we wrote by hand that pulls down all these transactions at the end of each month, matches them against orders in our database, ties in financial transactions from our bank, and then writes everything out in PTA format. It works well, but it is batch driven, kicked off manually, brittle to data format changes (especially from the bank), and completely unreusable by anyone else. Here's an example of what we finally end up with:
2024-11-21 * "Tyler Durden" "Stripe Charge ch_WH5HySsGFc6Wmmmmn3QHJ"
Assets:AccountsReceivable 309.00 USD
Income:Sales:FloatHubDevices -299.00 USD
Assets:Inventory:FLOATHUB-BORON3G-N2K -1.00 FLOATHUB-BORON3G-N2K {}
Expenses:COGS
Income:Sales:ShippingIncome -10.00 USD
2024-11-21 * "Tyler Durden" "Stripe Charge ch_WH5HySsGFc6Wmmmmn3QHJ"
Assets:AccountsReceivable -309.00 USD
Assets:UndepositedFunds 299.74 USD
Expenses:Fees:StripeProcessing 9.26 USD
In plain English, that shows we sold one unit for $299 plus $10 shipping, but then Stripe took their $9.26 payment processing fee leaving us $299.74. That gets deposited (possibly with other transactions) in a few days:
2024-11-24 * "WELLS FARGO BANK" "Stripe Payout po_INHxxFc6mnAkxHnj1QOU0s" Assets:WellsFargo:Checking Assets:UndepositedFunds -299.74 USD
If there was a way to integrate Stripe programmatically with our PTA system, then we could have a webhook occur the moment the transaction was complete. And that webhook could use a well understood interface specification to describe the data elements involved. We would not need to write any custom code or kick off any manual process, as the data would already be in our PTA system the moment the transaction went through.
But for that to work, we need some kind of programmatic interface to talk to. And for any integration glue or clever reporting code to be reusable, there probably needs to be some conventions or mappings around account names. If I call my provincial sales tax accrual account Liabilities:CA:PST:Incurred and you call yours Liabilities:Property:PaidPST, then how do we make a reusable reporting system understand which one (or ones) to use in a given context?
Maybe we can't? Maybe the simplicity and openness of PTA itself precludes structures of reusability. Maybe I'm thinking about this all the wrong way round? But it seems to me that if we can constrain PTA somewhat (make it a little bit more like QuickBooks), then we might be able to reap some benefits. If we put it behind some kind of REST-ful web interface and give it some naming conventions, there be a lot we can get out of that.
To be sure, we would still want to be fundamentally working with the same underlying plain and open data format. And you would always need a way to get your raw PTA file and walk away from the interface based system. Otherwise we would be exposing ourselves to the dangers of lock-in we talked about at the beginning of this post.
I've been thinking about building out a prototype of something like this for a while now. If you're involved in PTA or have any thoughts on any of this, I'd be very happy to hear from you: pta –at– modiot.com