8 ms·

Show HN: I've Built an Accounting System

214 points by journal 2y ago

It can create invoices and receive payments. Not quite production ready, yet. Only need PostgreSQL installed to try. I will add support to choose SQLite when they add native support for geography types.

bbor 2y ago
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? P.S. "Truck drivers of the office"...?
- journal 2y ago
  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.
  - PopAlongKid 2y ago
    >1. Intuit discontinued QB desktop on may 31 this year. That is false. They have switched to subscription licensing instead of perpetual license. Accountants can still purchase their version of Quickbooks, and yes the price just about doubled in the last few years, to about $1,000 but it's still available.
xupybd 2y ago
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 .
- journal 2y ago
  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?
  - xupybd 2y ago
    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.
    - journal 2y ago
      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.
codeonline 2y ago
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 https://github.com/PeterKneale?tab=repositories
- journal 2y ago
  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.
  - IMTDb 2y ago
    > Big things have small beginnings What about humble ones ? You come with a strong « I know best than anyone else » yet your project hasn’t even had 1 day of experience in the « real world ». > But, tell me what you want tested and add that to my list. Big numbers, small numbers, positive numbers, negative numbers, positive 0, negative 0, positive infinity, negative infinity, fractional numbers, irrational numbers, latin characters, non latin characters, invalid characters, emojis, dates in the past, dates in the future, dates that don’t exist, the list goes on; really
- HumblyTossed 2y ago
  Lots of very successful software never had those things.
  - bbkane 2y ago
    Your accounts ARE the tests!!
wg0 2y ago
Brutally minimized to first principles and to the very core. It's always about the journal and that's it. No fluff. Great project.
gamblor956 2y ago
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.
- minimalist 2y ago
  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?
  - tonyedgecombe 2y ago
    [flagged]
  - FredPret 2y ago
    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.
sotix 2y ago
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.
j45 2y ago
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.
- journal 2y ago
  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.
hersko 2y ago
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.
stevoh 2y ago
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/accounting/all-entities/journalentry 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.
- journal 2y ago
  Intuit has how many? I am one. Give it time.
  - 2y ago
emeril 2y ago
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...
zie 2y ago
Nice start! There are a few other OSS implementations, a list on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_accounting_software 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).
MichaelRo 2y ago
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.
- jjeaff 2y ago
  Except every company needs accountants. Only software companies need developers. There are roughly the same number of accounting jobs in the US as developer jobs. So it may just be due to a lack of software developers that cause the higher pay for developers. Although, outside of FAANG and similar software companies, my guess is that CPAs make more.
danielmarkbruce 2y ago
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.
Havoc 2y ago
>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.
- meiraleal 2y ago
  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
  - MichaelZuo 2y ago
    Can you list some examples from the past decade?
latentsea 2y ago
But does it support multi-currency?
revskill 2y ago
The accounting people are annoying because they keep using confusing terms to explain math. Or it is a kind of gatekeeping.
zarlo 2y ago
i am upset that both spaces and tabs are used in the sql code blocks the first 3 use tabs and the last 2 use spaces
atomicnature 2y ago
To the author: What are your thoughts on tiger Beetle? I think it provides most of the primitives that you mention in a highly optimized package (except hierarchical relationships).
Natochi 2y ago
looks very promising. gl!
rantingdemon 2y ago
It looks like a great product. I have to be honest though, I didn't read too much in detail - and this was the colour scheme seemed to "scream" at me. There is too much high-contrast colours (deep reds, etc.) Just my humble opinion. Which I am allowed to have :)
mr_gibbins 2y ago
An extraordinarily arrogant approach to presenting a project. The TEXT datatype is deprecated in most RDBMSs. A minor and insignificant point but following the 'remove the brown M&Ms' rider principle, it makes me question the integrity of everything else, especially given the insults in the readme and lack of professionalism throughout.
- systemvoltage 2y ago
  It’s autist, I’ll allow it.
- reportgunner 2y ago
  Why is the TEXT datatype deprecated ?
- Charlie_e 2y ago
  TEXT is absolutely not deprecated in Postgres, which this project is using for its example. It being deprecated by other RDMS seems irrelevant to mention.
zgk7iqea 2y ago
> I will add support to choose SQLite when they add native support for geography types. SQLite won't add that.
jtarchie 2y ago
I'm doing a little detective work here. 1. A posting like this appeared on [Reddit]( https://www.reddit.com/r/programming/comments/1e79xoz/creating_an_all_in_one_farming_application_in_c/ https://www.reddit.com/r/programming/comments/1e79xoz/creati...) two months ago. This repo started two months ago. The user [ApexProgrammer](https://github.com/ApexProgrammer https://github.com/ApexProgrammer) has one repo under their account. 2. These repos' first commits happened around July 12th, 2024, and July 9th, 2024. 3. One reference "Farm Manager," and another reference "Farm to Market." Questions: - Are these artifacts from a school project? - Are these AI-driven code repositories bent on world domination? - Are these questions to remain unanswered?
eqkRZX_wmv0jqp7 2y ago
Gross

214 points by journal 2y ago

bbor 2y ago

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? P.S. "Truck drivers of the office"...?

journal 2y ago
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.
- PopAlongKid 2y ago
  >1. Intuit discontinued QB desktop on may 31 this year. That is false. They have switched to subscription licensing instead of perpetual license. Accountants can still purchase their version of Quickbooks, and yes the price just about doubled in the last few years, to about $1,000 but it's still available.

xupybd 2y ago

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 .

journal 2y ago
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?
- xupybd 2y ago
  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.
  - journal 2y ago
    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.

codeonline 2y ago

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 https://github.com/PeterKneale?tab=repositories

journal 2y ago
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.
- IMTDb 2y ago
  > Big things have small beginnings What about humble ones ? You come with a strong « I know best than anyone else » yet your project hasn’t even had 1 day of experience in the « real world ». > But, tell me what you want tested and add that to my list. Big numbers, small numbers, positive numbers, negative numbers, positive 0, negative 0, positive infinity, negative infinity, fractional numbers, irrational numbers, latin characters, non latin characters, invalid characters, emojis, dates in the past, dates in the future, dates that don’t exist, the list goes on; really
HumblyTossed 2y ago
Lots of very successful software never had those things.
- bbkane 2y ago
  Your accounts ARE the tests!!

wg0 2y ago

Brutally minimized to first principles and to the very core. It's always about the journal and that's it. No fluff. Great project.

gamblor956 2y ago

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.

minimalist 2y ago
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?
- tonyedgecombe 2y ago
  [flagged]
- FredPret 2y ago
  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.

sotix 2y ago

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.

j45 2y ago

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.

journal 2y ago
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.

hersko 2y ago

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.

stevoh 2y ago

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/accounting/all-entities/journalentry 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.

journal 2y ago
Intuit has how many? I am one. Give it time.
- 2y ago

emeril 2y ago

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...

zie 2y ago

Nice start! There are a few other OSS implementations, a list on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_accounting_software 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).

MichaelRo 2y ago

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.

jjeaff 2y ago
Except every company needs accountants. Only software companies need developers. There are roughly the same number of accounting jobs in the US as developer jobs. So it may just be due to a lack of software developers that cause the higher pay for developers. Although, outside of FAANG and similar software companies, my guess is that CPAs make more.

danielmarkbruce 2y ago

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.

Havoc 2y ago

>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.

meiraleal 2y ago
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
- MichaelZuo 2y ago
  Can you list some examples from the past decade?

latentsea 2y ago

But does it support multi-currency?

revskill 2y ago

The accounting people are annoying because they keep using confusing terms to explain math. Or it is a kind of gatekeeping.

zarlo 2y ago

i am upset that both spaces and tabs are used in the sql code blocks the first 3 use tabs and the last 2 use spaces

atomicnature 2y ago

To the author: What are your thoughts on tiger Beetle? I think it provides most of the primitives that you mention in a highly optimized package (except hierarchical relationships).

Natochi 2y ago

looks very promising. gl!

rantingdemon 2y ago

It looks like a great product. I have to be honest though, I didn't read too much in detail - and this was the colour scheme seemed to "scream" at me. There is too much high-contrast colours (deep reds, etc.) Just my humble opinion. Which I am allowed to have :)

mr_gibbins 2y ago

An extraordinarily arrogant approach to presenting a project. The TEXT datatype is deprecated in most RDBMSs. A minor and insignificant point but following the 'remove the brown M&Ms' rider principle, it makes me question the integrity of everything else, especially given the insults in the readme and lack of professionalism throughout.

systemvoltage 2y ago
It’s autist, I’ll allow it.
reportgunner 2y ago
Why is the TEXT datatype deprecated ?
Charlie_e 2y ago
TEXT is absolutely not deprecated in Postgres, which this project is using for its example. It being deprecated by other RDMS seems irrelevant to mention.

zgk7iqea 2y ago

> I will add support to choose SQLite when they add native support for geography types. SQLite won't add that.

jtarchie 2y ago

I'm doing a little detective work here. 1. A posting like this appeared on [Reddit]( https://www.reddit.com/r/programming/comments/1e79xoz/creating_an_all_in_one_farming_application_in_c/ https://www.reddit.com/r/programming/comments/1e79xoz/creati...) two months ago. This repo started two months ago. The user [ApexProgrammer](https://github.com/ApexProgrammer https://github.com/ApexProgrammer) has one repo under their account. 2. These repos' first commits happened around July 12th, 2024, and July 9th, 2024. 3. One reference "Farm Manager," and another reference "Farm to Market." Questions: - Are these artifacts from a school project? - Are these AI-driven code repositories bent on world domination? - Are these questions to remain unanswered?

eqkRZX_wmv0jqp7 2y ago

Gross