>GAAP and IFRS compliant implementation of a forward-only double-entry accounting method
You may want to replace well most of your lead image. It sounds like gibberish to accountants. It's the accounting equivalent of saying this is an IPv6 compliant x64 CPU. The words are all from the right field but they're put together in a way that makes no sense to someone familiar with it.
That said accounting software is a fuckin trainwreck on both UI and features so I understand the hn urge to jump on this. Xero basically cornered the young company market by being a web based and being not entirely fuckin terrible.
Not knowing what they are doing is the basic premise of disrupting a market. It fails most of the times, but when it succeeds, big chances it was made by someone that didn't really understood the problem
It is a good start but the hubris here is quite high (and maybe not a bad thing). Funny readme but rather harsh. Seems I have been trolled enough to provide a response here...
I am not a fan of "Qwakbooks" and I can't believe I am about to defend it but... it does allow you to enter journal entries manually. In fact, you do not have to use any of the screens overlayed on top of the GL. The additional features are meant to help users do things faster and more efficiently. The details are not hidden at all but most users don't need to see them to be successful.
QuickBooks has all of the same core functionality including a well structured database too. You can interact with the QuickBooks Online API with a few endpoints and achieve the same thing much faster with scalability depending on which features you would like to use. If you don't believe me, just read through the API documentation which is really easy to follow. https://developer.intuit.com/app/developer/qbo/docs/api/acco...
So yes, this is a well structured database for an accounting system but beyond that there isn't much here.
Some other points:
"Due to its wide scope, the system is designed to be incomplete, allowing organizations to finalize the implementation." The customization involved to make this useable would be quite substantial and unaffordable unless you did it yourself (which would be a distraction from core business)
"Companies that adopt my system are far less likely to get audited..." This is false. You might survive an audit with a clean general ledger but it doesn't reduce the likelihood. There is also way more to audits than whether the TB balances - the substance of the transactions is obviously more important. ie. the accountant needs to know accounting otherwise audits with any system go poorly.
At quick glance... both this and QuickBooks do not have purchase order management, capex or prepaid amortization automation, approval workflows, muti-dimension transaction classification (for FP&A), or strong multi-company/currency support. These are all reasons why companies switch to a more robust (and usually more expensive) system. These features are needed for most but not all big companies with hundreds of employees moving around tens of millions of dollars.
As someone who was unfortunate enough to use Quickbooks professionally for several years, I laughed out loud at that meme on the bottom of the readme. Wish you all the luck.
Congrats on completing a rather involving project. Accounting isn't easy, I know coze I got a degree in it, although haven't pursued a CPA: I make a lot more as software dev and competition is way lower. Like, for every software company a few accountants would do, while it takes hundreds of developers, QA, HR, IT and other stuff to run it.
But I digress. There's no shortage of accounting software, I know coze my wife works for a company selling one :) But to survive and succeed the key is not in the software per se as in support. Continuous support for all the dumbass questions the clients may ask and continuously updating the software to keep up with the incessant small changes in the legislation. Updates without which one cannot even submit a balance sheet to the IRS and are only available upon subscription.
If a user understands accounting + software + databases, the problem and solution is quite simple. Unfortunately that subset is small. Given how much the world runs on software, one can imagine a company where a prerequisite to working there is understanding software and databases.
Cool project! I think it is worth pointing out contra accounts in the section where you discuss how accounts can increase and decrease. Debiting a contra-asset account would decrease its balance for example.
omg, I'm an actual old fart accountant...
"quickbooks" is good enough for small businesses (though I 100% appreciate the problems it has)
if you need something robust with more controls, you either just use netsuite/etc. or something more specialized for your industry
and FFS, only go the route of custom code as a last resort, you are better off slightly changing your business process to match whatever workflow/etc. is in the OTS ERP instead of having some cheap crappy dev (only crappy since most who do ERP programming are often not well paid) shoehorn your (likely ill conceived) process or report into the existing ERP...
As someone who has helped write and manage one used internally at a thousands of active employee organization I have some thoughts:
Most of these skip over authorization of transactions, which is very important in many organizations. I.e. Tootie wants to buy a new widget. Her supervisor probably has to approve it along with someone from budget/accounting to confirm we actually have the cash to pay for said widget, etc.
These authorization/workflow systems can get stupidly complex. Ours is rule/action based via regex matches against columns in the DB, and we support a _rules view on said table, to help achieve our goals and allow customization for each "module" or type of transaction that needs authorization.
The other thing often missing is auditing. We have auditors show up once or twice a year and pour over our transactions, audit and access logs. We record every I/U/D that happens against any table in the DB and have kept this information forever. We also have a support ticket system with integrated VCS that we use religiously to help handle the why, that also never erases information.
The next big thing often missing is reporting. We have thousands of reports. Every employee basically needs a few different ones. The key people(The accounting, payroll, AP and budget departments, tend to get dozens of reports per employee).
We perhaps overly abuse use PostgreSQL's access controls. Every user gets a login, and we use row and column level access controls. This way all of the above features are tied into access control. So if we make a generic report(say a birthday list), we can make it available for everyone, but a supervisor can only see their own employees and say the main manager at a particular location can only see records pertaining to their location.
Lastly, these systems do not live in isolation, we are often the first and last source for information. We import and export data automatically against a wide range of various systems, from SSO to random one-off messes some employee managed to get installed somewhere. Having a sane way to deal with IO is essential. Our current best method is for every system we have to two-way sync with(which almost always happens if the product lives past the first year), we keep a separate world-view of what we think their data is. This way when stuff inevitably breaks, we can easily track down if it's an us or them problem and get it routed appropriately. Since we keep both our world-view AND their world-view in our PostgreSQL database, we can replicate any previous state(due to keeping both world-views and precise auditing).
All of that makes sense. Using your database's user model is something I've thought about for different types of system, but never done.
I have a random, different question: what was the process by which this effort was approved? I can imagine a lot of companies (and their C[TI]Os) would say "Well, we should buy Oracle Financials and customise it".
How do you get a large enough org to afford this development effort, without getting an org that picks a prebuilt solution that can be customised?
It's because we are very old and we had custom software originally, way back in the 70 and 80's when we were first getting computers. When OpenVMS(the system our custom software was running on) was EOL'd, the existing team was given a lot of leeway to find a replacement. We were not very excited about the options and we had programmer staff already dedicated to the old custom software. Also users wanted "GUI" and "Web". So we implemented a new system in Python and PostgreSQL. PG functions are written in Python too.
I wasn't part of the original team, but I was there for the re-write. I brought in Python and PostgreSQL and I created two-way sync between the old OpenVMS system and PostgreSQL, so we could take our time and didn't need to have a big cutover date. That was a HUGE selling point that got everyone on board.
Thanks for posting, looks pretty polished to me! Lowkey love the design, super modern finance applications do make me irrationally afraid. Perhaps it's trauma from Navient-administered student loans...
I will say this is by far the most passionate README.md I've ever seen, lol;
Intuit didn't invent accounting; they've stolen it. Accounting existed before computers, databases, and software. Transactions were recorded in physical journals using pen and paper, which forced accountants to have a better understanding of company finances due to the process of manual entry, with little room for error. Now, the process has been automated through software, and the journal entries are hidden away, leaving only the final report to spot errors and fraud. None of you can call yourselves accountants; you're just QwackBooks users. The truck drivers of the office. Your boss thinks of you as a whiny, tail-dragging *****.
Do you have any particular reason/motivating experience for this ethos? Why not just use a piece of a paper/the default Excel ledger template/the `ledger` CLI tool if it's so important to do things by hand?
1. Intuit discontinued QB desktop on may 31 this year.
2. Intuit recently raised prices.
3. QB online has terrible navigation. I can make invoice in my system in less clicks.
4. I needed a feature to optionally print supporting documents with the invoice while having the ability to arrange the order of those documents. I then can integrate with mailing service and have PDF ready to mail programmatically. Instead of having to join PDFs together. (this feature doesn't work cause I can't afford IronPDF, it's the only PDF package I would use).
5. I don't like any limits on users or numbers of invoices I can have in my system.
6. Excel is error prone for more than a few records. Drag and drop accidentally one cell to another?
7. Multi-tenancy. I wanted to manage multiple companies without logging out.
Wow, this is really neat. Congrats on the launch. Are you seeking or accepting contributors? I’ll be installing it today.
I’ve unintentionally worked with and helped implement systemization and automation over a dozen different accounting systems and ERPs. They blur together.
Since I have a tech background, it’s not uncommon for me to say an accounting system or ERP is just line item rows moving though tables leaving their history behind… and how do you need it… and now it exists, haha.
A few questions:
- Journals and accounts are traditionally taught as the manual way to track different financial activities and ensure accurate reporting. Journals capture transactions as they happen, while accounts categorized them for analysis. Now that we have databases and reporting tools, is there a sense of where reporting or crunching things like profitability, job costing, etc could be built up from this?
Account code migration - when implementing a new accounting system, companies tend to dither over getting their GL right, or changing it up at implementation. Being able to maintain that history could help migration of data easier.
As someone who has helped design and lead implementations overall, with accountants handling their part, accounting depts can get caught in trying to do a lot with accounts and journals in lieu of a report.. while databases have allowed ERPs to report in ways (dimensions, etc) that might not be about accounts or journals alone.
Mostly I’m thinking about organizations that wanted to build up calculation of profitability by asset, or resource or service, or product, and how a project like this could help people easily do it from these first principles.
I have a few ideas in the works for accepting contributions that I will iron out in the coming days. I have some breaking changes in the works to make the journal more reliable and testable. The current implementation requires deep understanding of my vision.
AFAIK, North Korea, Russia, and United States, all have the same five accounts types and require double-entry.
This truly is a mission to rebuild an institution. My goal is to educate a new generation of accountants. The kind who can produce any report from raw journal entries and who can add new features to the journal.
Parent-child relationships help with reporting, but I notice the need to include parent-child relationships almost everywhere; locations, items (products/services), chart-of-accounts, users, tasks, etc.
I've not touched reporting because I know it will be easy to do.
If I get the journal, accounts, and transactions right, the rest is easy street.
One thing to mention at this time is that I don't see a need to manually enter journal entries. I'm ready to catch flack for saying this, but maybe... idk. Still in R&D phase.
Lack of manual journals would be a non-starter, I am actually not clear how a business could possibly run their books without manual journals.
An example: you make something that uses 5 inputs. I have inventory and cost of goods sold accounts for each of those inputs, but my invoices out to customers only reference the final product. This is where ERPs add insanely complex inventory management solutions. However, the simple way to deal with it instead is to use a manual journal to reconcile your inventory and cost of goods sold accounts monthly or however often you like.
Interesting example - Complex ERP inventory management and manufacturing experience here:
It seems reasonable to need manual adjustments, but I'm not sure if entries would be needed. Deciding how to make corrections and adjustments seems to be key in any manual journal entries, or not.
If journal entries derive from transactions elsewhere, chaining those together, or something to adjust them them is pretty reasonable.
About split entries like the scenario you've outlined? Cost of Goods Sold, vs manufacturing are all often in different parts of the ERP that may not tie back to journals always. Perhaps there is a pattern to setup that is repeatable. I'm not sure if you have a software background, but source code control of managing the bits of what changed when is important.
Another scenario where manual stuff might not work is if we have a just in time manufacturing process, and don't complete the finished goods until the items are on the truck and signed for by the driver (un damaged) so then you can finalize manufacturing, invoicing, shipping documents, etc. There's ways to reduce having to undo all of those if product is damaged between manufacturing and shipping. Of course this has it's own caveats. Implemented OK in SAP though.
Overall, a real need and goal is: reducing the amount accountants or anyone who works with an accounting data has to dump out data from the accounting system to "manipulate the data" to get a view of what happened/happening/needs to happen.
Unpopular take based on experience: It's been my experience that a good chunk of accounting groups that run around with their hair on fire that the system is somehow not working... calls in someone with database or analysis skills, to discover something wasn't done as needed, or not configured and implemented. In this way, the Technical ERP whisperers out there who are not accountants but handle the "in depth analysis"..
If you think Intuit is accounting than you don't really know what accounting is.
Off the top of my head... every major ERP has better functionality, customizability, and usability than this relatively simple take on a financial system. Even Workday... and that's an accounting system grafted on top of a HR platform.
This is basically yet another product created by a programmer that doesn't actually know enough about the field they're disrupting that they don't even realize that their disruption was obsolete a decade ago.
And no, as is this program couldn't be used to run a bodega, let alone an aircraft carrier.
Please elaborate more, my friend! Let's say that I was^W am a programmer who is seduced by the plain-text accounting / one-database-is-all-you-need notion and I think my needs will be simple, as I can keep the business of my bodega all in the RAM of my brain... Or at least I think I can.
How can this go wrong? What are some of the needs that compel the bodega owner to move on to more sophisticated tools? Is it because of calculating things like taxes and hourly rates and the like?
Imagine it’s the year 1890 at Standard Oil and they have a building full of filing clerks.
It’s run by the great John D Rockefeller, of which you can read more in the fantastic biography Titan. He’s a stickler for accurate accounting at all times.
Now they decide to buy a batch of barrels for all their oil.
- one clerk runs down to the cabinet with a file for all the items SO buys.
- another cross-references each item and fetches the files of the vendors for each of those items
- another cross-references with past invoices to get the most recent price for each item
- another gets a list of locations SO uses to store barrels
Now the purchasing manager looks at all this and decides which barrels to buy, from which vendor, how many, and where its getting delivered. So he writes out a purchase order / PO.
So back to the clerks:
- one runs along to file the PO in the PO filing cabinet. Remember, uncle John is watching and he wants to go to any cabinet or any manager at any time and get up-to-date details of what's going on.
- another one goes to the Items cabinet, finds the barrels we ordered, and notes on them that a PO was issued for this many barrels on such and such a date.
- one actually sends a copy of the PO to the vendor.
Skipping over some steps for simplicity, the barrels arrive one day with their invoice attached.
An Invoice! Now the army of clerks swing back into action. They get their guy at the warehouse to send them the original invoice that came stapled to the barrels. Then:
- one runs to the PO cabinet, finds the PO that was issued, marks it as done, and writes the invoice number on it.
- another one runs to the accounting department. There they make the double-entry bookkeeping entries to account for the money that is now owed to the vendor, and for the inventory value that has gone up.
- another one runs to the vendor cabinet and records the purchase on their file
- another one goes to the inventory cabinet and files a record updating the inventory balance for the barrel item
- someone files a copy of the invoice for future reference
Eventually we pay the invoice:
- a clerk keeps an eye on the payment terms for this and other vendors and calculates how much cash we have to send to each vendor each month
- another runs around to each paid invoice marking them as paid
- another one actually writes the cheques and mails them off
- someone has to tell the accounting department how much money we just paid, to which vendors, out of which bank accounts
Things get fun when these barrels eventually get sent to a production facility and filled with oil. Now the clerks have to do the correct filings to destroy the barrel items along with a quantity of oil, and create a new filled-barrel item. The cost of this depends on all of the cost of the barrel item, the oil, the labour, and some other things, all of which is determined using past entries.
This is a toy example and the complexity spirals from here. For example another invoice can arrive from the people who transported the barrels. Depending on your CFO, or the current accounting laws, you might want to include that in the cost of the barrels, or record it as a business expense.
You might have different departments who do their accounting separately, so now each transaction has to be split correctly. You might want to track the hourly rates of each employee and factor that into the cost of each finished-barrel item, and also tracking what everybody should get paid.
Add to this any idiosyncratic business rules stemming from management decisions, laws, unique physical constraints, or whatever.
An ERP system is all of these cabinets and their rules put into a relational database with a front-end.
Thank you for the excellent reply! I think I understand now... Once a business starts transacting in things other than a single type of money (say durable goods, consumables, services, or say other types of money) it becomes necessary to reconcile these non-money-denominated accounts. And for that, you need more than a single database, or single spreadsheet. You need a suite of persons or softwares that can __account__ for these stocks and flows, and the rules that come along with them.
And that is called ERP, of which "simple" money accounting is but one component of.
So root commenter's objection was more along the lines of: "those are some bold claims for mere money-accounting program. if you used a _real_ accounting program (as in an ERP) then you'd understand how complex peoples' needs can be". And the tone they phrased it elicited the downmods :)
I guess I understand. I still admire the OP and the frustration that fueled their desire to create a tool that works for them. And the tone of the readme is very endearing, it reminds me of the things my IRC friends would say to kick-off a lively discussion...
To add to your point, there's also other complexities like multiple currencies, keeping track of tax owed, and probably the biggest one: multiple people of all skill levels entering data into the system at the same time.
This comment doesnt deserve the downvotes its getting. If you ever work in an ERP system you will realize the complexity of tracking cost, inventory management (which is not just simple item, location quantity), purchasing, quotes, lead times, approval processes, BOM data structure, assembly, work orders, sales orders internal/external, etc etc. All these may boil down to basic cost account primitives but making a system that is a ledger then dismissing other solutions and saying you could manage the project of constructing an aircraft carrier make you wonder if the author has ever touched an ERP frontend or back. On top of that there are open source ERP and other smaller companies that make proprietary ERP that do not do some of the things intuit may do draw the ire of some.
I agree. Although do you think ERP as a discipline is actually successful in solving these kind of problems? It seems to be a field dogged by underperforming or failed systems.
None of you can call yourselves accountants; you're just QwackBooks users. The truck drivers of the office. Your boss thinks of you as a whiny, tail-dragging . That's why he needs just one of you who knows the entire system. Maybe you'll get lucky with an assistant, but most likely they'll cause more problems, because it'll be the boss's daughter and she doesn't give a .
Yes, this initiative has been fueled by hate directed towards Intuit and the overall accounting community for refusing to advance. It's like playing AoE with a noob who's refusing to advance to the next age because there will be more units, technologies, and strategies to manage. Most businesses have one accountant, which means this entire profession is one initiative away from not existing at all. There's no excuse for a modern accountant to not know at least SQL.
The patterns and practices that I demonstrate in the solution are nothing genius, it just took a while to put it all together, and it's very basic. Just one table with credit/debit columns, rows of which have to be organized into a transaction and linked with user-actions, like creating invoice, receiving payment, adjusting inventory, really anything, including foreign transactions.
When the calculator was invented, we didn't get stuck with a bunch of "calculator-operator" professions, so why does accounting get to stay stagnant?
In the UK with have a concept called a micro entity in the tax code. Micro entities have some fairly strict constraints on them (10 employees or less, turnover under £350,000, no foreign currency transactions and so on). Within those constraints the rules are fairly simple and most importantly HMRC provides online forms for filing your books.
I always wondered about starting from those constraints and working back to a basic accounting solution for your typical business person. It would probably cover 90% of the companies in the UK as most of them have really simple requirements.
What are your thoughts on plain text accounting? I know it's not really for businesses applications and really not for accountants but that's how I learnt accounting basics. I find that approach much better as I have total control of the structure. I suspect your application provides a similar level of control as the end company has to implement the details.
I've thought about separating the journal into a command-line application, where the end result might look exactly like plain text accounting, a sorta like ffmpeg for accounting. Plain text is part of my backup strategy.
If plain text are roads, then my approach is rail roads. A strict set of application logic so the operator doesn't get overwhelmed and is capable of managing large number of transactions at higher speeds of entry.
Then, it's just a matter of building more rail roads for any additional functionality. Once built, you'd probably never have to touch that code again.
>GAAP and IFRS compliant implementation of a forward-only double-entry accounting method
You may want to replace well most of your lead image. It sounds like gibberish to accountants. It's the accounting equivalent of saying this is an IPv6 compliant x64 CPU. The words are all from the right field but they're put together in a way that makes no sense to someone familiar with it.
That said accounting software is a fuckin trainwreck on both UI and features so I understand the hn urge to jump on this. Xero basically cornered the young company market by being a web based and being not entirely fuckin terrible.
Not knowing what they are doing is the basic premise of disrupting a market. It fails most of the times, but when it succeeds, big chances it was made by someone that didn't really understood the problem
It is a good start but the hubris here is quite high (and maybe not a bad thing). Funny readme but rather harsh. Seems I have been trolled enough to provide a response here...
I am not a fan of "Qwakbooks" and I can't believe I am about to defend it but... it does allow you to enter journal entries manually. In fact, you do not have to use any of the screens overlayed on top of the GL. The additional features are meant to help users do things faster and more efficiently. The details are not hidden at all but most users don't need to see them to be successful.
QuickBooks has all of the same core functionality including a well structured database too. You can interact with the QuickBooks Online API with a few endpoints and achieve the same thing much faster with scalability depending on which features you would like to use. If you don't believe me, just read through the API documentation which is really easy to follow. https://developer.intuit.com/app/developer/qbo/docs/api/acco...
So yes, this is a well structured database for an accounting system but beyond that there isn't much here.
Some other points:
"Due to its wide scope, the system is designed to be incomplete, allowing organizations to finalize the implementation." The customization involved to make this useable would be quite substantial and unaffordable unless you did it yourself (which would be a distraction from core business)
"Companies that adopt my system are far less likely to get audited..." This is false. You might survive an audit with a clean general ledger but it doesn't reduce the likelihood. There is also way more to audits than whether the TB balances - the substance of the transactions is obviously more important. ie. the accountant needs to know accounting otherwise audits with any system go poorly.
At quick glance... both this and QuickBooks do not have purchase order management, capex or prepaid amortization automation, approval workflows, muti-dimension transaction classification (for FP&A), or strong multi-company/currency support. These are all reasons why companies switch to a more robust (and usually more expensive) system. These features are needed for most but not all big companies with hundreds of employees moving around tens of millions of dollars.
Intuit has how many? I am one. Give it time.
That is fair, I can respect that! Keep going!
As someone who was unfortunate enough to use Quickbooks professionally for several years, I laughed out loud at that meme on the bottom of the readme. Wish you all the luck.
Brutally minimized to first principles and to the very core. It's always about the journal and that's it. No fluff. Great project.
Congrats on completing a rather involving project. Accounting isn't easy, I know coze I got a degree in it, although haven't pursued a CPA: I make a lot more as software dev and competition is way lower. Like, for every software company a few accountants would do, while it takes hundreds of developers, QA, HR, IT and other stuff to run it.
But I digress. There's no shortage of accounting software, I know coze my wife works for a company selling one :) But to survive and succeed the key is not in the software per se as in support. Continuous support for all the dumbass questions the clients may ask and continuously updating the software to keep up with the incessant small changes in the legislation. Updates without which one cannot even submit a balance sheet to the IRS and are only available upon subscription.
Without those the software is dead in the water.
But does it support multi-currency?
If a user understands accounting + software + databases, the problem and solution is quite simple. Unfortunately that subset is small. Given how much the world runs on software, one can imagine a company where a prerequisite to working there is understanding software and databases.
Cool project! I think it is worth pointing out contra accounts in the section where you discuss how accounts can increase and decrease. Debiting a contra-asset account would decrease its balance for example.
omg, I'm an actual old fart accountant... "quickbooks" is good enough for small businesses (though I 100% appreciate the problems it has) if you need something robust with more controls, you either just use netsuite/etc. or something more specialized for your industry
and FFS, only go the route of custom code as a last resort, you are better off slightly changing your business process to match whatever workflow/etc. is in the OTS ERP instead of having some cheap crappy dev (only crappy since most who do ERP programming are often not well paid) shoehorn your (likely ill conceived) process or report into the existing ERP...
Nice start!
There are a few other OSS implementations, a list on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_accounting_softw...
As someone who has helped write and manage one used internally at a thousands of active employee organization I have some thoughts:
Most of these skip over authorization of transactions, which is very important in many organizations. I.e. Tootie wants to buy a new widget. Her supervisor probably has to approve it along with someone from budget/accounting to confirm we actually have the cash to pay for said widget, etc.
These authorization/workflow systems can get stupidly complex. Ours is rule/action based via regex matches against columns in the DB, and we support a _rules view on said table, to help achieve our goals and allow customization for each "module" or type of transaction that needs authorization.
The other thing often missing is auditing. We have auditors show up once or twice a year and pour over our transactions, audit and access logs. We record every I/U/D that happens against any table in the DB and have kept this information forever. We also have a support ticket system with integrated VCS that we use religiously to help handle the why, that also never erases information.
The next big thing often missing is reporting. We have thousands of reports. Every employee basically needs a few different ones. The key people(The accounting, payroll, AP and budget departments, tend to get dozens of reports per employee).
We perhaps overly abuse use PostgreSQL's access controls. Every user gets a login, and we use row and column level access controls. This way all of the above features are tied into access control. So if we make a generic report(say a birthday list), we can make it available for everyone, but a supervisor can only see their own employees and say the main manager at a particular location can only see records pertaining to their location.
Lastly, these systems do not live in isolation, we are often the first and last source for information. We import and export data automatically against a wide range of various systems, from SSO to random one-off messes some employee managed to get installed somewhere. Having a sane way to deal with IO is essential. Our current best method is for every system we have to two-way sync with(which almost always happens if the product lives past the first year), we keep a separate world-view of what we think their data is. This way when stuff inevitably breaks, we can easily track down if it's an us or them problem and get it routed appropriately. Since we keep both our world-view AND their world-view in our PostgreSQL database, we can replicate any previous state(due to keeping both world-views and precise auditing).
All of that makes sense. Using your database's user model is something I've thought about for different types of system, but never done.
I have a random, different question: what was the process by which this effort was approved? I can imagine a lot of companies (and their C[TI]Os) would say "Well, we should buy Oracle Financials and customise it".
How do you get a large enough org to afford this development effort, without getting an org that picks a prebuilt solution that can be customised?
It's because we are very old and we had custom software originally, way back in the 70 and 80's when we were first getting computers. When OpenVMS(the system our custom software was running on) was EOL'd, the existing team was given a lot of leeway to find a replacement. We were not very excited about the options and we had programmer staff already dedicated to the old custom software. Also users wanted "GUI" and "Web". So we implemented a new system in Python and PostgreSQL. PG functions are written in Python too.
I wasn't part of the original team, but I was there for the re-write. I brought in Python and PostgreSQL and I created two-way sync between the old OpenVMS system and PostgreSQL, so we could take our time and didn't need to have a big cutover date. That was a HUGE selling point that got everyone on board.
Thanks for posting, looks pretty polished to me! Lowkey love the design, super modern finance applications do make me irrationally afraid. Perhaps it's trauma from Navient-administered student loans...
I will say this is by far the most passionate README.md I've ever seen, lol;
Do you have any particular reason/motivating experience for this ethos? Why not just use a piece of a paper/the default Excel ledger template/the `ledger` CLI tool if it's so important to do things by hand?P.S. "Truck drivers of the office"...?
There are multiple reasons.
1. Intuit discontinued QB desktop on may 31 this year. 2. Intuit recently raised prices. 3. QB online has terrible navigation. I can make invoice in my system in less clicks. 4. I needed a feature to optionally print supporting documents with the invoice while having the ability to arrange the order of those documents. I then can integrate with mailing service and have PDF ready to mail programmatically. Instead of having to join PDFs together. (this feature doesn't work cause I can't afford IronPDF, it's the only PDF package I would use). 5. I don't like any limits on users or numbers of invoices I can have in my system. 6. Excel is error prone for more than a few records. Drag and drop accidentally one cell to another? 7. Multi-tenancy. I wanted to manage multiple companies without logging out.
Wow, this is really neat. Congrats on the launch. Are you seeking or accepting contributors? I’ll be installing it today.
I’ve unintentionally worked with and helped implement systemization and automation over a dozen different accounting systems and ERPs. They blur together.
Since I have a tech background, it’s not uncommon for me to say an accounting system or ERP is just line item rows moving though tables leaving their history behind… and how do you need it… and now it exists, haha.
A few questions:
- Journals and accounts are traditionally taught as the manual way to track different financial activities and ensure accurate reporting. Journals capture transactions as they happen, while accounts categorized them for analysis. Now that we have databases and reporting tools, is there a sense of where reporting or crunching things like profitability, job costing, etc could be built up from this?
Account code migration - when implementing a new accounting system, companies tend to dither over getting their GL right, or changing it up at implementation. Being able to maintain that history could help migration of data easier.
As someone who has helped design and lead implementations overall, with accountants handling their part, accounting depts can get caught in trying to do a lot with accounts and journals in lieu of a report.. while databases have allowed ERPs to report in ways (dimensions, etc) that might not be about accounts or journals alone.
Mostly I’m thinking about organizations that wanted to build up calculation of profitability by asset, or resource or service, or product, and how a project like this could help people easily do it from these first principles.
I have a few ideas in the works for accepting contributions that I will iron out in the coming days. I have some breaking changes in the works to make the journal more reliable and testable. The current implementation requires deep understanding of my vision.
AFAIK, North Korea, Russia, and United States, all have the same five accounts types and require double-entry.
This truly is a mission to rebuild an institution. My goal is to educate a new generation of accountants. The kind who can produce any report from raw journal entries and who can add new features to the journal.
Parent-child relationships help with reporting, but I notice the need to include parent-child relationships almost everywhere; locations, items (products/services), chart-of-accounts, users, tasks, etc.
I've not touched reporting because I know it will be easy to do.
If I get the journal, accounts, and transactions right, the rest is easy street.
One thing to mention at this time is that I don't see a need to manually enter journal entries. I'm ready to catch flack for saying this, but maybe... idk. Still in R&D phase.
Lack of manual journals would be a non-starter, I am actually not clear how a business could possibly run their books without manual journals.
An example: you make something that uses 5 inputs. I have inventory and cost of goods sold accounts for each of those inputs, but my invoices out to customers only reference the final product. This is where ERPs add insanely complex inventory management solutions. However, the simple way to deal with it instead is to use a manual journal to reconcile your inventory and cost of goods sold accounts monthly or however often you like.
I have all the in the works, including complex assemblies and reporting.
I wish I had the $ to hire help.
Interesting example - Complex ERP inventory management and manufacturing experience here:
It seems reasonable to need manual adjustments, but I'm not sure if entries would be needed. Deciding how to make corrections and adjustments seems to be key in any manual journal entries, or not.
If journal entries derive from transactions elsewhere, chaining those together, or something to adjust them them is pretty reasonable.
About split entries like the scenario you've outlined? Cost of Goods Sold, vs manufacturing are all often in different parts of the ERP that may not tie back to journals always. Perhaps there is a pattern to setup that is repeatable. I'm not sure if you have a software background, but source code control of managing the bits of what changed when is important.
Another scenario where manual stuff might not work is if we have a just in time manufacturing process, and don't complete the finished goods until the items are on the truck and signed for by the driver (un damaged) so then you can finalize manufacturing, invoicing, shipping documents, etc. There's ways to reduce having to undo all of those if product is damaged between manufacturing and shipping. Of course this has it's own caveats. Implemented OK in SAP though.
Overall, a real need and goal is: reducing the amount accountants or anyone who works with an accounting data has to dump out data from the accounting system to "manipulate the data" to get a view of what happened/happening/needs to happen.
Unpopular take based on experience: It's been my experience that a good chunk of accounting groups that run around with their hair on fire that the system is somehow not working... calls in someone with database or analysis skills, to discover something wasn't done as needed, or not configured and implemented. In this way, the Technical ERP whisperers out there who are not accountants but handle the "in depth analysis"..
If you think Intuit is accounting than you don't really know what accounting is.
Off the top of my head... every major ERP has better functionality, customizability, and usability than this relatively simple take on a financial system. Even Workday... and that's an accounting system grafted on top of a HR platform.
This is basically yet another product created by a programmer that doesn't actually know enough about the field they're disrupting that they don't even realize that their disruption was obsolete a decade ago.
And no, as is this program couldn't be used to run a bodega, let alone an aircraft carrier.
Please elaborate more, my friend! Let's say that I was^W am a programmer who is seduced by the plain-text accounting / one-database-is-all-you-need notion and I think my needs will be simple, as I can keep the business of my bodega all in the RAM of my brain... Or at least I think I can.
How can this go wrong? What are some of the needs that compel the bodega owner to move on to more sophisticated tools? Is it because of calculating things like taxes and hourly rates and the like?
Imagine it’s the year 1890 at Standard Oil and they have a building full of filing clerks.
It’s run by the great John D Rockefeller, of which you can read more in the fantastic biography Titan. He’s a stickler for accurate accounting at all times.
Now they decide to buy a batch of barrels for all their oil.
- one clerk runs down to the cabinet with a file for all the items SO buys.
- another cross-references each item and fetches the files of the vendors for each of those items
- another cross-references with past invoices to get the most recent price for each item
- another gets a list of locations SO uses to store barrels
Now the purchasing manager looks at all this and decides which barrels to buy, from which vendor, how many, and where its getting delivered. So he writes out a purchase order / PO.
So back to the clerks:
- one runs along to file the PO in the PO filing cabinet. Remember, uncle John is watching and he wants to go to any cabinet or any manager at any time and get up-to-date details of what's going on.
- another one goes to the Items cabinet, finds the barrels we ordered, and notes on them that a PO was issued for this many barrels on such and such a date.
- one actually sends a copy of the PO to the vendor.
Skipping over some steps for simplicity, the barrels arrive one day with their invoice attached.
An Invoice! Now the army of clerks swing back into action. They get their guy at the warehouse to send them the original invoice that came stapled to the barrels. Then:
- one runs to the PO cabinet, finds the PO that was issued, marks it as done, and writes the invoice number on it.
- another one runs to the accounting department. There they make the double-entry bookkeeping entries to account for the money that is now owed to the vendor, and for the inventory value that has gone up.
- another one runs to the vendor cabinet and records the purchase on their file
- another one goes to the inventory cabinet and files a record updating the inventory balance for the barrel item
- someone files a copy of the invoice for future reference
Eventually we pay the invoice:
- a clerk keeps an eye on the payment terms for this and other vendors and calculates how much cash we have to send to each vendor each month
- another runs around to each paid invoice marking them as paid
- another one actually writes the cheques and mails them off
- someone has to tell the accounting department how much money we just paid, to which vendors, out of which bank accounts
Things get fun when these barrels eventually get sent to a production facility and filled with oil. Now the clerks have to do the correct filings to destroy the barrel items along with a quantity of oil, and create a new filled-barrel item. The cost of this depends on all of the cost of the barrel item, the oil, the labour, and some other things, all of which is determined using past entries.
This is a toy example and the complexity spirals from here. For example another invoice can arrive from the people who transported the barrels. Depending on your CFO, or the current accounting laws, you might want to include that in the cost of the barrels, or record it as a business expense.
You might have different departments who do their accounting separately, so now each transaction has to be split correctly. You might want to track the hourly rates of each employee and factor that into the cost of each finished-barrel item, and also tracking what everybody should get paid.
Add to this any idiosyncratic business rules stemming from management decisions, laws, unique physical constraints, or whatever.
An ERP system is all of these cabinets and their rules put into a relational database with a front-end.
Thank you for the excellent reply! I think I understand now... Once a business starts transacting in things other than a single type of money (say durable goods, consumables, services, or say other types of money) it becomes necessary to reconcile these non-money-denominated accounts. And for that, you need more than a single database, or single spreadsheet. You need a suite of persons or softwares that can __account__ for these stocks and flows, and the rules that come along with them.
And that is called ERP, of which "simple" money accounting is but one component of.
So root commenter's objection was more along the lines of: "those are some bold claims for mere money-accounting program. if you used a _real_ accounting program (as in an ERP) then you'd understand how complex peoples' needs can be". And the tone they phrased it elicited the downmods :)
I guess I understand. I still admire the OP and the frustration that fueled their desire to create a tool that works for them. And the tone of the readme is very endearing, it reminds me of the things my IRC friends would say to kick-off a lively discussion...
And so it has!
Thank you!
To add to your point, there's also other complexities like multiple currencies, keeping track of tax owed, and probably the biggest one: multiple people of all skill levels entering data into the system at the same time.
An excellent post, thanks.
The question was about a bodega owner ...
Bodega guy can probably get away with Excel (I shudder at the thought but it could work) or a very lightweight and cheap ERP (which doesn't exist)
This comment doesnt deserve the downvotes its getting. If you ever work in an ERP system you will realize the complexity of tracking cost, inventory management (which is not just simple item, location quantity), purchasing, quotes, lead times, approval processes, BOM data structure, assembly, work orders, sales orders internal/external, etc etc. All these may boil down to basic cost account primitives but making a system that is a ledger then dismissing other solutions and saying you could manage the project of constructing an aircraft carrier make you wonder if the author has ever touched an ERP frontend or back. On top of that there are open source ERP and other smaller companies that make proprietary ERP that do not do some of the things intuit may do draw the ire of some.
I agree. Although do you think ERP as a discipline is actually successful in solving these kind of problems? It seems to be a field dogged by underperforming or failed systems.
Hahaha, this is the most aggressive readme ever.
None of you can call yourselves accountants; you're just QwackBooks users. The truck drivers of the office. Your boss thinks of you as a whiny, tail-dragging . That's why he needs just one of you who knows the entire system. Maybe you'll get lucky with an assistant, but most likely they'll cause more problems, because it'll be the boss's daughter and she doesn't give a .
Yes, this initiative has been fueled by hate directed towards Intuit and the overall accounting community for refusing to advance. It's like playing AoE with a noob who's refusing to advance to the next age because there will be more units, technologies, and strategies to manage. Most businesses have one accountant, which means this entire profession is one initiative away from not existing at all. There's no excuse for a modern accountant to not know at least SQL.
The patterns and practices that I demonstrate in the solution are nothing genius, it just took a while to put it all together, and it's very basic. Just one table with credit/debit columns, rows of which have to be organized into a transaction and linked with user-actions, like creating invoice, receiving payment, adjusting inventory, really anything, including foreign transactions.
When the calculator was invented, we didn't get stuck with a bunch of "calculator-operator" professions, so why does accounting get to stay stagnant?
In the UK with have a concept called a micro entity in the tax code. Micro entities have some fairly strict constraints on them (10 employees or less, turnover under £350,000, no foreign currency transactions and so on). Within those constraints the rules are fairly simple and most importantly HMRC provides online forms for filing your books.
I always wondered about starting from those constraints and working back to a basic accounting solution for your typical business person. It would probably cover 90% of the companies in the UK as most of them have really simple requirements.
Luckily I retired before I got around to it.
Keep up the passion!
What are your thoughts on plain text accounting? I know it's not really for businesses applications and really not for accountants but that's how I learnt accounting basics. I find that approach much better as I have total control of the structure. I suspect your application provides a similar level of control as the end company has to implement the details.
I've thought about separating the journal into a command-line application, where the end result might look exactly like plain text accounting, a sorta like ffmpeg for accounting. Plain text is part of my backup strategy.
If plain text are roads, then my approach is rail roads. A strict set of application logic so the operator doesn't get overwhelmed and is capable of managing large number of transactions at higher speeds of entry.
Then, it's just a matter of building more rail roads for any additional functionality. Once built, you'd probably never have to touch that code again.
> It's like playing AoE with a noob who's refusing to advance to the next age
I will steal that, and there's nothing you can do to stop me!
> . . . the most aggressive readme ever.
I love it. It reminds me, in tone, of the Acknowledgements section of the Scsh manual: https://scsh.net/docu/html/man.html
Some big claims in that readme for a project with no tests :)
Lots of C# repo's here demonstrating unit/integration/acceptance testing within dockerised containers if you need some examples https://github.com/PeterKneale?tab=repositories
Big things have small beginnings.
I think Donald Rumsfeld said something about unknown unknowns.
But, tell me what you want tested and add that to my list.
Lots of very successful software never had those things.
Your accounts ARE the tests!!