The end of the accounting search [LWN.net]

By Jonathan Corbet
May 5, 2023

Some things, it seems, just cannot be hurried. Back in 2007, your editor first started considering alternatives to the proprietary accounting system that had been used by LWN since the beginning. That search became more urgent in 2012, and returned in 2017 with a focused effort to find something better. But another five years passed before some sort of conclusion was reached. It has finally happened, though; LWN is no longer using proprietary software for its accounting needs.

The system used until now — QuickBooks — was a legacy from the beginnings of the company in 1997. It has long exhibited a full litany of the sorts of misbehaviors endemic to proprietary systems. Regular (paid) updates were forced, despite the fact that new versions brought little in the way of new capabilities. Crashes were frequent; QuickBooks users know to make backups every few minutes to avoid losing work. The software had arbitrary limits meant to force "upgrades" to the "enterprise" version. More recently, Intuit has discontinued support for the desktop version entirely in an effort to force all users to its online, paid-by-the-month service.

Enough was finally enough; your editor took some time to go back and review the various systems that had been considered in the past. It turned out that the scripts developed to pry data out of QuickBooks still worked — at least, after a somewhat belated update to Python 3. In the end, the option that won out was GnuCash.

How the decision was made

There is a wealth of free accounting systems available for Linux systems. Many of them are highly complex and solve a much bigger problem; they include features like inventory tracking, customer-relation management, and more. Such systems are unwieldy to work with and difficult to get started with. In truth, many of them appear to have been developed as platforms for consulting businesses, though surely nobody would deliberately make their software complex and tricky just to motivate clients to purchase their services. LWN prefers to not spend its hard-earned pennies that way, and has no need for all of that complexity, so those systems were dropped from consideration early on.

At the other end, there are a number of accounting systems that are based on plain-text files and an associated set of programs. These systems are much easier to work with and are adaptable to most needs. Such a system could have been made to work for LWN, but they tend to lack some useful features. Check writing and report generation, for example, tend not to be well supported. The user interface for many operations is a text editor; this is often seen as an advantage, but it becomes less so as the number of transactions grows. There are advantages to a graphical interface designed for the job at hand.

GnuCash is not a perfect program by any means, but it does provide the accounting features that LWN needs, along with a reasonable graphical interface and a minimum of extra complexity.

The 2017 restart included a number of requirements that any new accounting system had to meet:

Importing and exporting of data had to be doable — and relatively straightforward. Getting our QuickBooks data into GnuCash took a bit of scripting using the capable (if poorly documented) Python bindings. Another set of scripts has since been written to import data from the site and from our bank account. GnuCash has a reasonably capable import mechanism for the data formats exported by banks, complete with a Bayesian system to assign transactions to accounts, but a bit of scripting makes the process quicker yet.
Basic accounting operations needed to be simple, and indeed they are.
The generation of forms for our legal reporting requirements was on the list. GnuCash has some features to handle this, though not for US forms. In the end, this is a task that we now simply hand off to our accountant, who handles it with our annual taxes. A related requirement is check printing, which is important for a business to be able to do; more on that below.
Ease of integration with the rest of LWN's operation was mentioned above; the Python bindings make most things fairly easy to do.
The last requirement had to do with the future longevity of the system — how healthy is its community? The GnuCash project, having started in 1997, is slightly older than LWN; it is still here a quarter-century later and still making releases. GnuCash probably will not go away anytime soon. That said, its development community is smaller than one might like, and progress is not rapid.

All told, the requirements listed all those years ago have been met well enough for the change to be made.

Some further impressions

There are a number of aspects of GnuCash that seem not quite finished. For example, it has had the ability to use an SQL database (PostgreSQL, MySQL, or SQLite) for many years, but the native XML format is still described as "the most stable and established" and recommended for most users. Storing data in PostgreSQL does work, and startup time is marginally faster when using it. Sadly, multi-user access is not supported, even when using PostgreSQL. Another example is the reconciliation process, which doesn't remember what the previous reconciled value was and, instead, makes up something strange.

GnuCash has a report-generation mechanism that has clearly had a lot of effort put into it; the system is designed to be extensible by end users. The unfortunate part is that the extension language is Scheme, and it is, for the most part, undocumented. Scheme looks like Lisp but isn't really Lisp; the number of people who know it well is sure to be small. The prospect of creating a new report for GnuCash (or improving an existing one) can be a bit daunting; see the implementation of a balance sheet for an example. Your editor, in the end, found it easier to just create new reports outside of GnuCash in Python.

The ability to print checks has always been on the list. Even in the US, we write far fewer checks than we once did, but the need still does come up. GnuCash has that ability, and it can be made to work with just about any check format. The language used to add a new check format is rudimentary, but it gets the job done in the end. One annoying feature of GnuCash's check printing is that address information must be entered every time a check is printed, even if the recipient's address is stored as, for example, a vendor in GnuCash.

The biggest thing we lose in this move is the ability to export data in a format that our accountant can read directly into his proprietary tax-preparation system. He is willing to work with us, though, and believes that the reports generated from GnuCash will be enough to get the job done without a lot of additional effort (and expense). Perhaps he, too, is tired of hearing your editor's complaints about QuickBooks for all these years is prepared to do almost anything to be done with that.

In the end, GnuCash is good enough to do what LWN needs it to do. It is a nice feeling to have gotten rid of the one proprietary program used in LWN's operations, and to have better control over our accounting data. The new system is working well enough that your editor is kicking himself for having waited so long to commit to the change.

The end of the accounting search

Posted May 5, 2023 16:30 UTC (Fri) by easwarh (subscriber, #131924) [Link] (6 responses)

Having been a decade-long user of GnuCash for personal finances, I would encourage LWN to post their scripts and workarounds in a public open source repository, partly as documentation of said poorly-documented Python bindings, as well as to speed integration of some of the bank account import quirks that needed working around into Gnucash proper for interested hackers

The end of the accounting search

Posted May 6, 2023 6:55 UTC (Sat) by tonyblackwell (guest, #43641) [Link] (5 responses)

Yes please!
Where are the updated scripts to retrieve data from Quickbooks?
Tony

QB-escape scripts

Posted May 6, 2023 14:20 UTC (Sat) by corbet (editor, #1) [Link] (3 responses)

The "escape from QuickBooks" scripts are where they've been since the beginning: git://git.lwn.net/qb-escape.git . I'll ponder whether some of our post-escape scripts are suitable for addition there.

QB-escape scripts

Posted May 7, 2023 15:58 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

> I'll ponder whether some of our post-escape scripts are suitable for addition there.

If there isn't a strong reason to keep them private, I would lean towards publishing them, preferably along with the source code of LWN itself :-)

QB-escape scripts

Posted May 8, 2023 2:59 UTC (Mon) by tonyblackwell (guest, #43641) [Link] (1 responses)

Updated Python 3 versions?

QB-escape scripts

Posted May 8, 2023 3:10 UTC (Mon) by corbet (editor, #1) [Link]

What's there is current, just checked.

The end of the accounting search

Posted May 21, 2023 16:07 UTC (Sun) by vivekgani (guest, #164240) [Link]

I recently (spring 2023) made updates and added documentation to the scripts Jonathan Corbet (and contributors) here: https://github.com/erikmack/qb-escape

Would love to see someone package this into a standalone migrater tool so non-technical folks could use it!

Scheme

Posted May 5, 2023 17:17 UTC (Fri) by Wol (subscriber, #4433) [Link] (17 responses)

You might find that's wider known than you realise. It's the preferred extension language for Gnu, I believe.

For example, I use lilypond and, while it can get thoroughly confusing, the bulk of lilypond is written in scheme. The workhorses that get the job done are C++, but pretty much everything above that is either scheme or lilypond's own domain-specific (music) language.

I don't know how many other projects use it, though ...

Cheers,
Wol

Scheme

Posted May 5, 2023 18:08 UTC (Fri) by geert (subscriber, #98403) [Link] (14 responses)

My university started using Scheme as the introductory programming language in the first year of the computer science and engineering degrees after I graduated (before that, we had Pascal). It didn't last long, and was replaced by Java.

Scheme

Posted May 5, 2023 22:48 UTC (Fri) by gutschke (subscriber, #27910) [Link] (13 responses)

Pascal was designed as a teaching language. It shows. It's not a great development language unless you make serious changes to the language definition. But even as a teaching language it falls flat and is frequently too verbose and cumbersome.

Lisp and its various dialects are amazing as an embedded language and for the longest time didn't have much competition. But this language family also works really well as an introductory language for teaching basic CS concepts. It's easy to explain the entirety of the language in a few hours, and the utter lack of boilerplate code makes it a perfect fit to quickly outline algorithms and to introduce the concepts that a first year CS students needs to pick up. It also has the benefit of being a functional language.

I found that it is difficult to teach people to think in terms of functional programming, if they were first introduced to procedural concepts. The other way rounds is mostly effortless though. These days, knowing both paradigms is important and thus starting with Lisp still gives an advantage.

Of course, if you are teaching an applied degree (i.e. software engineering vs. computer science) the focus shifts. Lisp might not really have much of an advantage if you don't want to make a speedrun through introducing as many fundamental algorithms as possible. And in the long run, few people will stick with Lisp exclusively. You still need to learn everything else that is out there. But I wouldn't outright discard it as an introductory language. If you have a good professor, it can be a valuable tool and provide great abstractions for discussing problems.

I personally wouldn't want to throw Java into that mix. Way too many rigid rules and boilerplate code that can confuse a beginner. Python is fine although maybe a bit too relaxed to unleash on an inexperienced programmer without some handholding. A sane subset of Javascript can also work in a similar way to Lisp, but again it requires discipline to avoid its pitfalls.

Scheme

Posted May 8, 2023 3:32 UTC (Mon) by marcH (subscriber, #57642) [Link] (5 responses)

> These days, knowing both paradigms is important and thus starting with Lisp still gives an advantage.

For this OCaml checks all the boxes you listed and more, it's the perfect teaching language. It's as functional as Lisp but with a readable syntax[*] and much more. But of course people want to be taught a language they have a chance of using in some future job and OCaml is even further than Lisp there.

Maybe it's Haskell cousin would raise fewer eyebrows? I don't know Haskell at all.

[*] https://dwheeler.com/readable/sweet-expressions.html

Scheme

Posted May 8, 2023 3:57 UTC (Mon) by gutschke (subscriber, #27910) [Link]

Thank you for that link. I hadn't previously seen that suggestion, but I do like the idea. It's a minor amount of syntactic sugar that dramatically improves readability. Nicely done.

I also fully agree with you that there are more modern alternatives that have similar or nicer properties than plain old Lisp. I could see them be used as a preferred teaching language.

OCaml

Posted May 9, 2023 18:32 UTC (Tue) by patrakov (subscriber, #97174) [Link] (2 responses)

Regarding OCaml, I have seen some real-world use. See for example this job post: https://ahrefs.com/jobs/ocaml-developer

OCaml

Posted May 9, 2023 20:55 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (1 responses)

One of my favorite tools is written in OCaml: Unison https://www.cis.upenn.edu/~bcpierce/unison/ I almost use it daily, and apart from a couple of cross-platform/cross-version issues it's been a fantastic tool to work with.

OCaml

Posted May 9, 2023 21:15 UTC (Tue) by marcH (subscriber, #57642) [Link]

I know OCaml is very far from a toy language but my comment stands.

I know this comments section looks a bit like social media but the comments here are not as binary. More specifically here, a programming language and community can be in a very large number of nuanced states besides "dead" and "alive".

Scheme

Posted May 23, 2023 19:50 UTC (Tue) by ArneBab (guest, #42896) [Link]

It’s great to see that link here!

Did you know that a derivative of readable (wisp¹) is now used for the Guix Workflow language for reproducible science in HPC? Ricardo Wurmus who realized that showed it to people who were uneasy with the regular Scheme look of the code and the experience was very positive:

> »Wisp allows people to see code how Lispers perceive it. Its structure becomes apparent.« — Ricardo Wurmus

I built wisp 10 years ago with the thought at the back of my mind to use it in teaching one day, and now I use it to show error correction codes in a networking lecture and to represent concurrent algorithms for distributed systems.

¹: for more information on wisp and the source of the quote see https://www.draketo.de/software/wisp

Scheme

Posted May 8, 2023 7:47 UTC (Mon) by geert (subscriber, #98403) [Link] (2 responses)

I think they switched from Java to Python after that...

Now, let's compare with what my daughter had to endure in high school:
1. Scratch,
2. Visual Basic in PowerPoint[*],
3. Python.

[*] Seriously?!? I thought we wanted to attract more people in STEM education, not scare them away?

Scratch

Posted May 11, 2023 8:02 UTC (Thu) by ringerc (subscriber, #3071) [Link] (1 responses)

Scratch is actually pretty cool.

I was able to easily and quickly implement a program for reading values from an ultrasonic sensor in graphical Scratch. Quite astonishing. I've been programming for decades and expected graphical block programming to be a nightmare - I was pleasantly surprised.

It would not be my choice for real programs but it's quite serviceable for learning basic embedded stuff.

Scratch

Posted May 23, 2023 19:53 UTC (Tue) by ArneBab (guest, #42896) [Link]

I think that Scratch is great to explore an API, so it’s quite expected that it was easy to get going with it. And it uses the concepts of programming without introducing the "why doesn’t it compile?!" madness :-)

Scheme

Posted May 8, 2023 14:28 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (3 responses)

The university I work for (and where I studied many years ago because it seems I settled down in this city) used to teach an ML (Standard ML of New Jersey) as a first language, and then teach a Lisp, and some C I think - this is for Computer Scientists which was the degree I took.

By the time I left for industry the first time it was teaching Java as a first language and I believe that continues today. Programming is obviously far more necessary across numerate disciplines than it once was, and so almost all the sort of courses where decent maths is a pre-requisite for year one now teach programming, at least optionally, except for one. Medicine is already absolutely up to their necks in requirements, as well as teaching a longer schedule and presumably there just isn't room to teach them programming. Outside of CS, the first language is usually Python, although in some disciplines it's R instead (and in Electronics specifically it's C).

Because Java is, if nothing else, broadly useful, today's CS students needn't learn any other language well, which is especially ironic when the university hires them, especially as interns or on short fixed terms, and obviously we aren't a Java shop, so they need to learn a new language. They are shown C during their mandatory first year classes, because Java doesn't have allocation and that's important, but it's not as though first year courses are fail-one drop out, so who cares if you do OK everywhere else?

Modern CS students can explicitly choose to learn Haskell, and I think there are still opportunities that might lead to Lisp and Prolog in the optional courses somewhere, but it's not unusual to get a fresh graduate whose only practical programming language is Java, which is a bit disappointing.

One really obviously missed opportunity is that while Rust looks superficially like a semi-colon language, like C or Java, in many ways it's an ML wearing a trench coat. So people who learned when I did are like "Wait a minute..." because oh yeah, these aren't statements which end in a semi-colon, these are expressions with a semi-colon at the end to turn them into statements. And these types seem awfully recalcitrant for a language which inherits from C, but once you realise this is an over-grown Hindley–Milner type system it becomes much clearer why 5 isn't true and "x" isn't an array and so on. So if you were still teaching ML then you've actually got a clear route to the future. Oh Well.

Scheme

Posted May 8, 2023 19:06 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

Since we're apparently posting "here's what my college does," well, here's what I experienced several years ago:

* CS 1 (the introductory course for freshmen) uses Python. I have no experience with this as I placed out of it. I think it previously used C++ at some point?
* Data Structures (effectively CS 2) uses C++. The class structure consists of two lectures introducing a new data structure that you have probably never seen before (I specifically remember "leftist heaps," which are just extremely unbalanced heaps that you can merge quickly), an assignment where you're supposed to implement that data structure (as in, you submit code, they compile it, and it has to produce exact byte-for-byte correct output over a range of test inputs), and a lab (where you do a more basic version of the assignment and can ask TAs for help). Every week. For the entire semester. As you might imagine, this is where a lot of students drop out. OTOH, this was probably the most useful course of my entire four years at that place, because it taught me how to Actually Get Shit Done, which is a rather important skill in this business.
* "Computer Organization" (basically, low level stuff for people not on the hardware track) uses x86 assembly, by way of DEBUG.EXE on 16-bit DOS on 32-bit Windows on 64-bit Windows. No, I don't know why they did that either.
* Programming Languages had a mandate to teach us logic programming (SWI Prolog), functional programming (Oz, but only the functional parts) and the Actor model (a weird Java dialect which the professor invented himself). I'm told that the other prof. used more sane languages in their iteration of the course (though at least Prolog makes some sense). For the Prolog part, I distinctly remember an exam where we were asked to implement a linked list in Prolog, and I had no idea what I was doing and just wrote out the list invariants as logical formulae... and was very surprised to later get full points for that answer.

Scheme

Posted May 9, 2023 11:37 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Oz and the Java-like (Salsa?) are pretty specific. As is the CompOrg name (though DOS wasn't used then; we had "Dave's bombs" instead to debug). If you went to RPI, this sounds almost exactly what it was like in the late 00's as well. The Oz-and-Salsa-loving professor was on sabbatical when I took it, so we got Prolog, Java, Scheme, and (I think) Python in the ProgLang course instead. Friends who took it when he returned kept finding Salsa compiler bugs…

Scheme

Posted May 12, 2023 1:39 UTC (Fri) by jschrod (subscriber, #1646) [Link]

Ah, story telling time, I'll take it up -- from the other side of the teaching fence.

I'm from Germany and had the opportunity to get a full-paid position in my university for my PhD time. In US terms, this position is a mixture of teaching and research assistant position, available for those with a Master degree and working towards a PhD. (This was in 1990, btw.)

My professor (PhD advisor) had an annual lecture called "principles of programming languages". I was supposed to develop and supervise the practical exercises accompanying that lecture. Well, the main point the lecture wanted to drive home: Specific programming languages are irrelevant. If you, as a CS master student, have learned to program any imperative, functional, object-oriented, or logical language (like Prolog), then you should be able to learn a new language of the same paradigm quickly, if you understood the principles behind it.

So, when I started to design the practical exercises for this lecture, I decided that my students would have to learn a new programming language every 2 weeks as far as to produce a program for a sensible requirement. The learning exercise was: It doesn't matter if you indent your program structure (Python) or if you have lots of parenthesis (the Lisp family) -- what matters are, what data and control structures are available to you in your program design.

Anectodical note: Don't do this after a thorough analysis of the technical means you have to provide to the students. I remember especially two issues:

1) Exceptions, which were not well supported in many languages in 1991. So I had to make available a CLU compiler for the exercises, within 2 weeks, since this was -- at this time -- the best practical example what it means to have exceptions as a fully-fledged 1st-order part of the language. (Still, I think that Liskov is way underrated for her contributions to the development of programming languages. Besides her work on exceptions, her SIGPLAN paper "Programming with Abstract Data Types" in 1974 actually coined the term `abstract data types'!)

2) My professor insisted to cover class-instance vs. prototype-instance models in the part of the OO language introduction. So I had to devise an excercise for a problem that's suitable to prototype-instance concepts. Nowadays, we could just use Javascript -- but this was 1991. The work to set up a working Self system for my students (for a 2 weeks assignment!!) was outrageous. But I have bought into it, and I got through it.

The interesting part of this story is: There were quite some students who shied away from the demands of the lecture and (mandatory) practical excercises. But for those, who did it together with us, it was a great experience. Many of my master students that supported my PhD came off from that course. In fact, some of them were helping me to set up the excercise environments during the course, while actually taking the course -- and those were the ones who later took off and have now excellent positions, both in companies and universities.

I'm still proud to have been a part of their journey towards the understanding that expression doesn't matter prinicipally. (We can discuss, where it matters.) Models and understanding the principles are the gains you get from a thorough university education. There is a "everything changes so fast" attitude I'm experiencing today from others in my field (mainly software and business process architect, with a lasting footage in the open-source development community in my spare time). Well, from a CS point of view, no. The principles remain the same.

Scheme

Posted May 5, 2023 21:45 UTC (Fri) by bartoc (guest, #124262) [Link] (1 responses)

All those parentheses give me hives.

In seriousness though Guile is a fine language, it's just quite exclusive to the GNU ecosystem, and has worse tooling support than some other languages. Also it's somewhat annoying to get working on windows.

I've never really seen the beauty of lisp myself, I think homoiconicity is not really a super useful property, and is an artifact of how you define things, in many ways.

Scheme

Posted May 6, 2023 15:18 UTC (Sat) by Wol (subscriber, #4433) [Link]

> All those parentheses give me hives.

You've not programmed in PL/1 then, I take it :-)

Cheers,
Wol

The end of the accounting search

Posted May 6, 2023 0:15 UTC (Sat) by gerdesj (subscriber, #5446) [Link] (2 responses)

My little company in the UK (South Somerset) used to run accounts on Sage. We started out with spreadsheets (2000) and fell into the classic trap of "what is everyone else using?" when we got to the point that we needed to grow up.

Sage is a UK firm (tick) but what an absolute bunch of wankers. Perhaps I should explain. Me and my boys and girls (etc) have roughly 20 concurrent years experience with Sage. Whenever there is a problem then you will have your network diagnosed as being at fault. Then your AV and so on and so forth. Little Sage is based on text files. Bigger more (very) expensive Sage is a proper DBMS based thing. They could have used MySQL for little Sage or both but ... profits - fuck off customers! They now have a weird Windows service based thing for little Sage that seems to manage file locking. That is sadly the way of things sometimes. We still have loads of happy Sage customers on our books but that's their bag, until the wheels fall off for some reason, then we get to debate network stability.

Anyway. We took on a customer from Bridgwater - a manufacturing firm, around 2014. Their MD was an accountant in a former life and he and his IT bod had created a thing they called UzERP - basically an ERP system written in PHP with a PostgreSQL backend from scratch. Several more companies ended up using it and we migrated to it in roughly 2016. We retain a programmer to look after it.

I remember the old days of wanting to run a report and having to get someone to logout so I could use their Sage licence. Nowadays, I either use the rather weird webby front end or dive in with pgsql or even R.

As big Jon alluded to in the article (and for many past years), an accounting system is a bit of a pain when you want to actually own your stuff. I've had a poke at GNUCash and it looks jolly capable but we are all in on UzERP. I'm still not too sure why because I am nearly the only member of the firm that actually uses Linux all the time (Arch, actually) and I never got really involved in the accounting stuff too much. Then again, why should I - I'm the MD 8)

The end of the accounting search

Posted May 11, 2023 10:49 UTC (Thu) by nowster (subscriber, #67) [Link] (1 responses)

In the big UK VAT change of 2008 (from 17.5% to 15%), we had a lot of recurring (stored) invoices in Sage Line 50. You could change the default VAT rate for newly created invoices, but not for stored ones. Sage themselves were no help. I had to reverse engineer the binary file format to patch the values.

It was then that I found they were storing money amounts using 32 bit (single precision) floats, with the base unit being a whole GBP, contrary to decades of good accounting practice in avoiding rounding errors. (You can't represent £0.01 exactly in binary IEEE 754 formats.)

The end of the accounting search

Posted May 11, 2023 17:07 UTC (Thu) by cwitty (guest, #4600) [Link]

That's scary. Representing money with (binary) floating point is pretty bad, but using single-precision floating point is amazingly bad. That can't even represent £16,777,217; you'd have to use a value that was off by one GBP (either up or down). And if you don't want to gain or lose as much as £0.01 in accounting error, you'd need to restrict yourself to numbers much less than a million.

The end of the accounting search

Posted May 6, 2023 14:13 UTC (Sat) by karim (subscriber, #114) [Link] (5 responses)

I've been following this series since its beginning and was sort of excited when I read that the search was finally over -- I've been eagerly looking for a replacement for my company's proprietary accounting system since forever. But then I read the word that killed my excitement: lisp. ... Back to reading my boring Saturday morning news ...

Lisp

Posted May 6, 2023 14:18 UTC (Sat) by corbet (editor, #1) [Link] (3 responses)

Lisp (Scheme, really) is only needed if you want to do custom reports within GnuCash. LWN's usage involves no Lisp code.

Lisp

Posted May 6, 2023 17:09 UTC (Sat) by atai (subscriber, #10977) [Link] (1 responses)

A TurboTax clone in Lisp. Or Congress can legislate tax code in Lisp

Lisp

Posted May 12, 2023 0:53 UTC (Fri) by jschrod (subscriber, #1646) [Link]

Please -- I don't think this type of comment is appropriate for LWN.net.

Thank you for considering this for your next post.

Lisp

Posted May 8, 2023 0:18 UTC (Mon) by karim (subscriber, #114) [Link]

Thanks for adding this detail. Appreciated.

The end of the accounting search

Posted May 10, 2023 9:12 UTC (Wed) by peter-b (subscriber, #66996) [Link]

Scheme is a wonderful programming language. Definitely a plus from my point of view.

Remember, in matters of taste there is no "correct".

The end of the accounting search

Posted May 8, 2023 14:39 UTC (Mon) by paulj (subscriber, #341) [Link] (5 responses)

How do the plain text accountancy tools stack up? There's almost a movement on this that has spring up in the wake of 'ledger':

https://plaintextaccounting.org/

The end of the accounting search

Posted May 9, 2023 11:17 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

It's mentioned in the article (and previously as well across the saga IIRC). The main issues seem to be around reporting and check printing features. There was also a complaint about files getting big, but I do one file per month to keep active files smaller at least… There is noticeable lag when `hledger` reads everything though, so something that uses a cache may be better suited.

There's also the issue of what the accountant on the other side of the equation can use. I doubt `ledger` and friends are in that toolbox.

The end of the accounting search

Posted May 9, 2023 13:00 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

LWN did do an article looking at ledger - but that's ~10 years ago. The plain-text-accounting movement seems to have made a lot of progress and developed a lot more tools around then. Including Web UIs.

Certainly, the idea of a clean, well described, human-readable, text format to write and easily manipulate your accounts in seems interesting (nothing prevents tools building other caches and indices around this). Particularly when "vendor lock in" is such a common complaint with accountancy systems.

The end of the accounting search

Posted May 9, 2023 14:05 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

> Certainly, the idea of a clean, well described, human-readable, text format to write and easily manipulate your accounts in seems interesting

Until you're a big company and have auditors sniffing around wondering why it's so easy to manipulate the figures ...

Okay, there's ways around it, but many accountants are much happier if the means of editing things aren't there ... Of course we know anybody can get round it all, if they wish ... :-)

Cheers,
Wol

The end of the accounting search

Posted May 9, 2023 14:39 UTC (Tue) by paulj (subscriber, #341) [Link]

The same people who have "email Word docs and Excel spreadsheets with sensitive data to partners" as core working practices, IME. But, those people are generally going to use Intuit, Sage, Xero, or somesuch.

Note that by "manipulate" I meant "write tools to transform (reduce, visualise, collate, extract, etc.)". ;)

The end of the accounting search

Posted May 21, 2023 22:55 UTC (Sun) by ProsaicHacker (guest, #165233) [Link]

I did a contract that had me creating cost value Journal Entries for buildings owned by the organization over the previous 100 years.

Due to IT's bizarro restictions on installing tools I used a lot of portable apps including a screen control language
the directly use the UI of the accounting app to insert and delete records from the pre-production DB.
In a important demo of the system,the director of account noticed a flaw in the form of a internal tracking number.
It was a dash in the wrong place.
While they were discussing plans to hire a data entry person to do Journal Entries back out the transaction and reenter a new one,
I unload the database, fixed the mistake with Perl, and reloaded it. They watched me do it and were in horror that it could be done even in pre-prod. They thought all system were immutable.

I never did that kind of thing in front of accountants again.

The end of the accounting search

Posted May 11, 2023 1:39 UTC (Thu) by gtirloni (subscriber, #85631) [Link] (37 responses)

> Check writing

I'll never understand why people still use checks. Is it a US thing?

The end of the accounting search

Posted May 11, 2023 4:50 UTC (Thu) by Wol (subscriber, #4433) [Link] (15 responses)

Why do people use cheques? Because a LOT of people don't have internet banking.

How are you going to send money between two people (NOT businesses)? If - the sender especially - does not have access to bank transfer, then a cheque is the only available solution.

Cheers,
Wol

The end of the accounting search

Posted May 11, 2023 8:27 UTC (Thu) by geert (subscriber, #98403) [Link]

The task mentioned was "check writing", i.e. for the sender, and in the context of a business.

FWIW, over here, even transactions between individuals are done electronically; transferring money electronically between two IBAN account numbers (that's all of EU plus a few more) comes without additional charges. Transfers beyond that, meh...

The end of the accounting search

Posted May 11, 2023 8:40 UTC (Thu) by ringerc (subscriber, #3071) [Link]

How does practically anybody not have access to Internet banking?

I was in very rural mountain India 10 years ago and most people there did banking on extremely basic mobile phones using net banking and txt.

How's anyone in the US not have it?

The end of the accounting search

Posted May 11, 2023 8:58 UTC (Thu) by rschroev (subscriber, #4164) [Link] (12 responses)

Over here in Belgium, we instruct our bank to transfer a specific amount of money from our bank account to the recipient's bank account, specified by its bank account number. These days we do it electronically, in the olden days we filled out forms (like this one: https://nl.wikipedia.org/wiki/Overschrijving#/media/Besta..., though they looked a bit different before SEPA) and handed them to our bank. That was more cumbersome, but essentially the same process. It works, and worked, the same for transfers to businesses vs individuals.

Invoices generally include pre-printed transfer forms (some banking apps can use a photo of them to copy the information from them). For other uses, you used to get blank forms from your bank; I suppose you can still get those if you really don't want to use internet banking.

The end of the accounting search

Posted May 11, 2023 9:40 UTC (Thu) by Karellen (subscriber, #67644) [Link] (11 responses)

What's the difference between "a cheque" and "a paper transfer form that indicates which account to send money from, who the recipient is, and the amount to transfer"?

Isn't a cheque just a (partially) pre-printed transfer form?

The end of the accounting search

Posted May 11, 2023 9:50 UTC (Thu) by rschroev (subscriber, #4164) [Link] (10 responses)

Suppose Alice wants to pay Bob.

Cheque:
- Alice fills out the cheque
- Alice gives or sends the cheque to Bob
- Bob hands the cheque to his bank for processing
- Bob sees the money in his bank account

Bank transfer:
- Alice fills out the form
- Alice hands the form to her bank for processing
Note: the above two steps are almost always done via a website or an app and combined in one easy operation
- Bob sees the money in his bank account

The end of the accounting search

Posted May 11, 2023 10:26 UTC (Thu) by Wol (subscriber, #4433) [Link] (4 responses)

> Note: the above two steps are almost always done via a website or an app and combined in one easy operation

You clearly don't know any elderly people ...

My parents-in-law have a (dumb) mobile which sees minimal use. They have a smartphone which they don't even know how to turn on.

My father-in-law has a laptop. Whenever ANYTHING changes it is a support call to the family. Given that things like bank websites change regularly, the "time to learn" is roughly DOUBLE the "time between changes". Cue considerable unending frustration or a scream of "just write a cheque !!!"

I agree. Online banking is MUCH better in oh so many ways. But when dealing with people 70+, internet banking is just TORTURE!

Cheers,
Wol

The end of the accounting search

Posted May 11, 2023 10:33 UTC (Thu) by rschroev (subscriber, #4164) [Link] (3 responses)

There is still the option to do things the old fashion way (at least I think so; I haven't tried in 20+ years).

The end of the accounting search

Posted May 11, 2023 12:57 UTC (Thu) by joib (subscriber, #8541) [Link] (2 responses)

Over here in northern Europe it's only the old people who use the few remaining physical bank offices anymore, making them unusable for anybody else (pensioners have the time to spend the day queuing in the bank, people with kids and careers don't).

(If you need to negotiate a loan or something, you book an appointment, which works, the above refers to the basic bank teller functions.)

The end of the accounting search

Posted May 11, 2023 13:15 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

You're lucky :-)

Here in a different part of Northern Europe, even if you can find a bank branch the cashiers have all been replaced with ATMs :-)

(Actually, the ATMs outnumber the cashiers, usually just one roving person asking "can I help you?")

The one gain from this is the coin counting machines, although I'd rather have fewer coins, with real value, rather than the current worthless crop ... I remember when 1d was actually worth something - "four chews for a penny" - now they're about 20p each!

Cheers,
Wol

The end of the accounting search

Posted May 12, 2023 8:03 UTC (Fri) by jem (subscriber, #24231) [Link]

>Here in a different part of Northern Europe, even if you can find a bank branch the cashiers have all been replaced with ATMs :-)

The ATMs are going next. Here we have, on average, one ATM per 200 square kilometer – 300 ATMs per 1 million inhabitants.

The end of the accounting search

Posted May 11, 2023 13:24 UTC (Thu) by geert (subscriber, #98403) [Link]

> - Bob hands the cheque to his bank for processing
> - Bob sees the money in his bank account

There used to be a second option: Bob receives the money in cash. Banks stopped doing that because of the high risk of fraud[1].
Perhaps this option is still available in some countries for people without a bank account?

> - Alice hands the form to her bank for processing
> Note: the above two steps are almost always done via a website or an app and combined in one easy operation

You can still hand it out manually, if you're willing to pay a fee.

[1] A memorable case from 40y ago, involving ca. 2M€, unfortunately only in Dutch: https://nl.wikipedia.org/wiki/William_Vandergucht

The end of the accounting search

Posted May 18, 2023 19:39 UTC (Thu) by irvingleonard (guest, #156786) [Link] (3 responses)

There's a feature that the cheque has: the person being paid doesn't have to share his/her banking details with the payer, and has the option of caching it on any account that he/she sees fits. Also, it works without electricity (ran out of juice? got the phone broken/stolen? got your account locked because reasons? etc).

The end of the accounting search

Posted May 19, 2023 14:28 UTC (Fri) by kleptog (subscriber, #1183) [Link] (2 responses)

> There's a feature that the cheque has: the person being paid doesn't have to share his/her banking details with the payer, and has the option of caching it on any account that he/she sees fits.

That feature is covered by using other payment services. For example Tikkie allows the user to make payment links for free which they send to the other person who pays it using by instructing their own bank. The underlying transfers are done by SEPA-Instant so for the users it's instant and the users only see the account number of Tikkie. There are many such services. If you're wondering who pays: it's not free for business users (>€2500/day).

As for the out of juice scenario, that's really a corner case. Then again, I live in a country with one the of the most reliable power networks in the world (>99.99%). Almost all the time you can just pay later when stuff comes online again. Such a narrow use case is not enough to sustain cheques.

The end of the accounting search

Posted May 19, 2023 16:01 UTC (Fri) by nijhof (subscriber, #4034) [Link] (1 responses)

The real corner case is trying to buy a new phone after breaking the old one, where you need the old phone to confirm any payment.

The end of the accounting search

Posted May 21, 2023 17:46 UTC (Sun) by j0057 (subscriber, #143939) [Link]

Two work-arounds come to mind: use the bank's web application to make the transfer from your desktop/laptop, or go to a physical shop and pay with your banking card.

The end of the accounting search

Posted May 11, 2023 8:35 UTC (Thu) by geert (subscriber, #98403) [Link] (19 responses)

I think so.

I used to have a checkbook, and wrote one or two checks ever. That was 25 years ago, before personal checks were abolished.
Bank cheques survived a bit longer, they were used to e.g. buy a car. But I think nowadays you just show some other bank document to prove payment.

The end of the accounting search

Posted May 11, 2023 13:09 UTC (Thu) by Wol (subscriber, #4433) [Link] (18 responses)

They've abolished your personal checks? I got given a cheque just yesterday ...

Mind you, I think we've stopped using Bankers Drafts ...

Cheers,
Wol

The end of the accounting search

Posted May 11, 2023 13:12 UTC (Thu) by geert (subscriber, #98403) [Link] (17 responses)

Apparently in 2002
https://en.wikipedia.org/wiki/Eurocheque

The end of the accounting search

Posted May 11, 2023 16:04 UTC (Thu) by Wol (subscriber, #4433) [Link] (16 responses)

Interesting ...

But the Eurocheque (or rather its rationale) disappeared with the Single European Currency. Surely national cheques carried on? They were talking about scrapping UK cheques, but the concern about people outside the digital system meant they soldier on. However, cheque guarantee cards disappeared a long while ago.

Cheques are now used mostly between individuals, or for paying deposits or sending money safely through the post. I'm not sure of the rules, but I think they changed them recently, a bank MUST bounce a cheque in the first two days or so, otherwise they can't reclaim the money unless the recipient is accused of fraud or knowing dishonesty. It wasn't unknown for a bank to clear a cheque and release funds, then maybe weeks later decide to bounce it and reclaim the money, long after the recipient had used it.

Cheers,
Wol

The end of the accounting search

Posted May 11, 2023 22:10 UTC (Thu) by anselm (subscriber, #2796) [Link] (12 responses)

But the Eurocheque (or rather its rationale) disappeared with the Single European Currency. Surely national cheques carried on?

Here in Germany I haven't seen a cheque in 20 years. According to statistics, nowadays less than 0.1% of transactions between non-bank entities involve cheques.

The problem with cheques is that if Alice gives Bob a cheque, Bob has to trust that Alice has enough money in her bank account for the cheque not to bounce when Bob's bank asks Alice's bank to honour the cheque. Cheques can take considerable time to clear between banks and therefore even if Bob's bank has credited him with Alice's money quickly just to be nice, they might want it back if it turns out that Alice's bank says that Alice isn't good for it after all. The big advantage of Eurocheques was that they were each guaranteed up to a certain amount (400 DM in Germany, IIRC) and therefore represented a much safer way to be paid.

(This delayed-bounce effect is at the heart of the popular scam where someone overpays you for something with a cheque and then asks you to send the excess money back using Western Union or some other payment scheme that is hard to undo. If you do that, what will happen is that, later on, the cheque bounces and (a) you're out the money that your bank wants back, plus the money that you sent to the scammers, and (b) you may get a friendly visit from the money-laundering police.)

The end of the accounting search

Posted May 12, 2023 10:37 UTC (Fri) by farnz (subscriber, #17727) [Link] (11 responses)

The thing that basically killed the cheque in the UK was a regulatory mandate that all payments into personal accounts were final (from the point of view of the recipient) 5 working days after the payment was posted to the account by the bank. The only exceptions to this are if a court orders the banks to reverse the payment; this is the process used in cases of fraud, for example, where a court can make such an order.

Effectively, this meant that banks had two choices, neither of them great for the bank:

Delay posting a cheque payment for 6 months after it was received - but this annoys customers, who want to use that money, and don't get why a cheque from a trusted family member isn't accepted as money for 6 months.
Take the risk themselves of a cheque bouncing after the 5 day period is up.

Neither of these are great options for the banks, and so they've made huge efforts to get a third option going - one where nobody uses cheques because electronic payments are simply easier and faster. We're now trying to address the social problem this causes for people who have aged to the point of not being able to learn a new system (electronic payments via Internet banking) to replace the one they learnt as a young adult in the 1970s or earlier (cheques) - it'll be interesting to see if a solution to this problem is found other than the trivial one (of waiting for that group to die out).

The end of the accounting search

Posted May 12, 2023 19:41 UTC (Fri) by Wol (subscriber, #4433) [Link] (10 responses)

But why does a bank require six months for fraud checks on cheques ... ?

Cheers,
Wol

The end of the accounting search

Posted May 15, 2023 9:15 UTC (Mon) by farnz (subscriber, #17727) [Link] (9 responses)

Because of a whole bunch of things adding up:

Cheques are asynchronous and have no "good standing" requirements for acceptance (unlike cards or direct debits), so the first sign that there's payee fraud is the payer checking their statements and disputing a cheque payment. With quarterly statements, up to 90 days can elapse before the payer even has a statement to check, and they have a further 30 days to raise issues, getting us to 120 days from date of fraud to detection.
Once the payer's bank is aware that the payer alleges that a cheque was fraudulent, they have 30 days to find a suitably verifiable image of the cheque, and validate it against their records for the payer's signature etc - this time is needed because the verifiable image may not be stored online, but can be in an offsite vault and hard to recover, as can the records for payer's signature etc. This gets us to 150 days.
Finally, if the payer's bank agrees with the payer that the cheque was fraudulent, they have 30 days to notify the payee's bank of the allegation of fraud; this gets us to 180 days.

Of these, the only one that could reasonably be reduced is the final one - where there's a delay notifying the payee's bank of the allegation of fraud, but that only gets you down to 150 days instead of 180. The 90 days to the next statement is unavoidable, since I cannot tell that a fraudulent cheque has been written against my account until I see a statement; the 30 days to notify the bank is a standard thing to allow for postal delays, holidays etc preventing me from checking the statement as soon as it's printed. 30 days for the payer's bank to verify the allegation of fraud is also normal - this gives time for the bank to get the appropriate backup tape from deep storage, verify signatures etc, and otherwise do their due diligence to confirm that an allegation of fraud has merit.

The critical difference is that with cheques, the whole process is asynchronous to the payer's bank - it gives you a chequebook, and some arbitrary time later, you write a cheque, exposing your bank to one set of fraud risk. An indeterminate time later, the payee pays the cheque into their bank (if this cheque is a forgery, this exposes the payer's bank to another set of fraud risk); and then a further delay happens before the payer's bank is notified of the payment. When the payer's bank is notified of the payment, it can take action to handle fraud - but this has happened after it's been exposed to the fraud risk, and is thus too late for any action to be taken to reduce risk. With bank transfers, the payer's bank is in the loop as the payer asks for the transfer to happen - the payer's bank can thus do whatever it wants to do to reduce the fraud risk to a level it deems acceptable.

The end of the accounting search

Posted May 15, 2023 12:10 UTC (Mon) by Wol (subscriber, #4433) [Link] (8 responses)

> Of these, the only one that could reasonably be reduced is the final one - where there's a delay notifying the payee's bank of the allegation of fraud, but that only gets you down to 150 days instead of 180.

Let's knock off another 60 days ... Pretty much EVERY current account I've had is monthly statements (with "no transaction? no statement!"). I think banks may have tried to move to quarterly statements 20 years ago, but for current accounts that doesn't seem to have stuck.

And given the propensity for banks to demand mobile numbers and spew texts, surely "cheque no N has been presented for payment, please contact us if you didn't write it" isn't hard?

At the end of the day, pretty much all of your timescales could be massively reduced, if the banks cared.

Cheers,
Wol

The end of the accounting search

Posted May 15, 2023 13:29 UTC (Mon) by farnz (subscriber, #17727) [Link] (7 responses)

Quarterly statements are commonly used by the disabled as a way to align statement arrivals with the time their carers have to help them reconcile their accounts. Insisting that you must take monthly statements if you want to use cheques is a way to disenfranchise this group, which doesn't seem like a good trade-off.

And if you have a mobile phone, why not use the bank's automated telephone or SMS banking service to make the payment instead? This is better from the bank's point of view, because it means that the bank can do as many checks as it wants up-front, before payment is presented the to payee's bank, rather than having to do its checks after the payee has apparently "received" the money.

This is why the banks don't care to reduce this timescale - fundamentally, they want the payer to get in touch with them and arrange payment, so that they can control their exposure to risk up-front. A cheque inherently involves the payee getting in touch to demand payment, and thus by the time the bank is handling a cheque, it's too late to do anything to reduce the risk; all the bank can do is move the risk around between the payer, the payer's bank, the payee and the payee's bank.

The end of the accounting search

Posted May 15, 2023 13:59 UTC (Mon) by Wol (subscriber, #4433) [Link] (6 responses)

As a carer myself, I've never come across your quarterly scenario... and seriously, how does the person being cared for align the quarterly statement with the payment quarter or whatever ... what's the difference between three monthly statements and one quarterly statement, apart from the fact that monthly means you've got the statements when you need them, not when the bank deigns to send them.

SMS banking service? What's that? As for automated telephone banking service, I really can't imagine the elderly / disabled people I look after being able to cope with it ...

And while things may have changed, what you describe does not sound like my experience of banking fraud checks. (Your description of bank incompetence seems pretty good, though.) You say the banks want time to do fraud checks? Then why can't the recipient's bank just forward a scan of the cheque and the paying in slip to the drawer's bank, which runs said fraud checks before it sends the money. Simples. Might catch a lot of scams, seeing as they'd be able to run "does the recipient's bank account look dodgy?" checks!

Cheers,
Wol

The end of the accounting search

Posted May 15, 2023 14:12 UTC (Mon) by farnz (subscriber, #17727) [Link] (5 responses)

The difference between quarterly statements and monthly is entirely regulatory - you get 30 days after the statement date to challenge line items, in which the bank must prove that the line item is legitimate, after which the burden of proof shifts to you as the account holder to prove that it's not. If you increased that time to 90 days, then monthly statements would be just fine for these people (whose specific brain injuries stop them reading or writing; they're capable of getting people to read and write for them, but not doing it themselves).

And there's no need to align the statement with the payment quarter or whatever - you need a carer who comes in every 3 months and who's financially literate enough to help you reconcile your accounts and ensure that all line items are either legitimate, or have been challenged, in that 30 day period.

Remember, also, that in English law, you've made the payment by giving the payee the cheque; it's too late for the bank to run its checks at this point, since in law the payment has been made unless the cheque is proven to be fraudulent - but what the bank wants is to stop the payment unless it's proven to be legitimate within the bank's tolerance for risk. So, for your scheme to work in English law, the recipient's bank needs to forward a scan of the cheque and the paying-in slip before the cheque is written - I hope the problem with this is obvious.

Fundamentally, it all comes down to risk management - the bank is very happy to accept some level of fraud in order to permit normal transactions to go through; cheques prevent the bank from choosing what level of fraud it's happy to accept, since it cannot vary its checks based on the total amount at risk if it later turns out that fraud took place. The old cheque guarantee card was a way to limit the risk to the bank; the card said what the maximum transaction amount it guaranteed was, and if you exceeded that limit, the entire cheque was not guaranteed. So, when my card said £20, any transaction over £20 where I used a cheque for part or all of the amount was not guaranteed by the scheme; my last guarantee card said £500, which meant the bank was at risk for up to £500 each time I used a cheque covered by the scheme.

The end of the accounting search

Posted May 15, 2023 17:01 UTC (Mon) by Wol (subscriber, #4433) [Link] (4 responses)

> Remember, also, that in English law, you've made the payment by giving the payee the cheque; it's too late for the bank to run its checks at this point, since in law the payment has been made unless the cheque is proven to be fraudulent - but what the bank wants is to stop the payment unless it's proven to be legitimate within the bank's tolerance for risk. So, for your scheme to work in English law, the recipient's bank needs to forward a scan of the cheque and the paying-in slip before the cheque is written - I hope the problem with this is obvious.

Has the law changed, then? That WAS the case with a cheque guarantee card. And how come my bank bounced my cheque because it failed fraud checks? Are you telling me my bank acted illegally?

Cheers,
Wol

The end of the accounting search

Posted May 15, 2023 17:17 UTC (Mon) by farnz (subscriber, #17727) [Link] (3 responses)

In English law, and this has been true for a very long time (and is still true today), the fact that you've paid with a cheque is an acknowledgement that you owe money. Once I have a cheque from you, I do not need to get into whether or not you owed me money, just into whether or not the cheque bounced; if it bounced, you owe me the full value of the cheque, simply on the basis that the cheque bounced.

This means that if the cheque isn't a forgery, the payer's bank has no option but to honour it, even if it suspects fraud is involved, and then to deal with the resulting upset customer who wants the bank's help dealing with the fraud. With online payments, the bank can intervene earlier, and reduce its exposure to fraud by being very clear to its customer that the fraud checks are failing, and you need to take extra action to make the payment happen.

Now, the bank is well aware that not all customers will pay attention to the failed fraud checks, but I've encountered them twice in the wild; once paying someone who went (legitimately) by multiple names, where confirmation of payee raised an issue because I'd used his stage name, and the account I had for him didn't have his stage name attached (easily fixed), and once paying for goods I had ordered online, where the bank warned me of its fraud suspicion and I cancelled the order instead - which turned out to be the right thing, because I later saw other people complaining that they'd bought the same item with same serial number from the seller as I was trying to buy, but months before I did, and it hadn't been delivered.

Had I wanted to, I could have overriden the bank's fraud checks in both cases, and told it that I did know what I was doing. I chose to follow the bank's advice, but I didn't have to. With a cheque, in the second case, however, I'd have been stuffed - he'd have the cheque, and would be able to claim that by sending him a cheque, I had agreed to pay him.

The end of the accounting search

Posted May 15, 2023 22:24 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> This means that if the cheque isn't a forgery, the payer's bank has no option but to honour it, even if it suspects fraud is involved, and then to deal with the resulting upset customer who wants the bank's help dealing with the fraud. With online payments, the bank can intervene earlier, and reduce its exposure to fraud by being very clear to its customer that the fraud checks are failing, and you need to take extra action to make the payment happen.

So how come my bank bounced my cheque, when it had no real reason to be suspicious?

Cheers,
Wol

The end of the accounting search

Posted May 15, 2023 23:15 UTC (Mon) by farnz (subscriber, #17727) [Link]

Because bouncing the cheque is the only option the bank has to move risk around - by bouncing a cheque, all the risk is moved to the payee, who can either chase the payer for new payment (using the bounced cheque as evidence that you owe them money), or discover that the payer is no longer in reach of English law, and that they've lost their money.

In contrast, with a system where the payer engages in a dialogue with their bank to ask them to issue a payment, the bank can move risk around to the payer, not just to the payee, by asking the payer steadily more probing questions until the bank is convinced that the total risk to the bank is low enough.

And remember that there's not just fraud risk involved - there's also the risk of someone writing more cheques than they have money to cover, leaving the bank with a bad debt, and there's the risk of having to actually offer some form of customer service to a customer who's been upset by the experience. By having the payer engage in a dialogue with their bank, which ends with either payment made, or payer terminating the dialogue, the bank only ever has to handle the risk its own customer represents; with a cheque written by the payer, the payer's bank also has to handle the risk the payee represents if the cheque is bounced, and has additional risk from the payer being upset because they thought the payment had cleared out of their account, and now cannot afford to pay the money they owe.

Fundamentally, the bank's goal is to reduce fraud risk to a level where it will eat the cost of fraud, and to reduce the other risks to zero because the bank would prefer to not spend any money at all on customer service (as is reflected in the quality of CS you get from a UK bank nowadays). Cheques are not compatible with this, since when things go wrong, the payer's bank has to supply CS to both the payer and payee, and has to handle fraud by the payee, while the payee's bank has to supply CS to the payee, and has to handle fraud by the payer. Internet banking works well for this, since when things go wrong, the payee is not dealing with the banks at all, and all the risk is borne by the payer's bank, who has to provide CS to the payer, and who can reduce the fraud risk to whatever level it's happy to accept.

The end of the accounting search

Posted May 20, 2023 13:34 UTC (Sat) by ghane (guest, #1805) [Link]

I am in Singapore, which has quite good instant transfers, Net banking, and 99% broadband penetration at home. Yet companies still issue cheques, and accept them.

> In English law, and this has been true for a very long time (and is still true today), the fact that you've paid with a cheque is an acknowledgement that you owe money. Once I have a cheque from you, I do not need to get into whether or not you owed me money, just into whether or not the cheque bounced; if it bounced, you owe me the full value of the cheque, simply on the basis that the cheque bounced.

This is important.

Also important is the cheque issuance process. In small owner-operated firms, the cheque book is with the Accountant, who checks invoices, prepares the Payment Voucher, and then the cheque. This is presented to the Owner (the Sole Signatory), who glances at the Payment Voucher, mutters: "what? So much?", and signs. Despatch is left to the Accountant.

If the Internet Access is given to the Accountant, the Owner believes it will be misused. If the Internet Access is with the Owner, then he is too important and busy to type in stuff (the typical owner here has a $1000 iPhone but is proud that he does not have a PC, his secretary does).

On the other side, the Payee gets a piece of paper (and the cheque has space to write the Invoice number it is for), so it is easy to reconcile in your ledger. No need to wait for an end-of-month statement, to see who paid you.

tl;dr: People use QR Codes, mobile payments, credit cards, stored wallets, etc all day. But businesses still prefer cheques. Because their workflow is set up that way.

The end of the accounting search

Posted May 15, 2023 9:18 UTC (Mon) by kleptog (subscriber, #1183) [Link] (2 responses)

> But the Eurocheque (or rather its rationale) disappeared with the Single European Currency. Surely national cheques carried on? They were talking about scrapping UK cheques, but the concern about people outside the digital system meant they soldier on. However, cheque guarantee cards disappeared a long while ago.

Cheques were already dying/nearly dead, the rise of electronic transactions (credit/debit cards) in the 90's did that. With the transition to the Euro everything needed to be redesigned anyway so it was a good moment to stop with Eurocheques. You could cash international cheques for a while, but that's stopped too (which is annoying when some UK/US company decides to send you a cheque for some reason e.g. dividends, there's literally no way to cash it).

There was an alternative in NL: the acceptgiro. Which is essentially a paper transaction request. The difference with cheques is that you send the acceptgiro to your own bank rather than send it to the receiver who sends it to their bank who sends it to your bank. The clearance time of acceptgiros is much shorter and the risk for the bank is zero.

Since 2020/2021 banks have stopped accepting acceptgiros as well, basically due to lack of usage. However, because it's just a transaction request, older users can just scan them with their bank app and approve the transaction that way. This is mostly used by organisations who are looking for donations.

My understanding is that cheques are still popular in the US because electronic transfers between banks are difficult and not standardised, whereas the Federal Reserve offers cheap cheque handling. In SEPA transactions are few seconds anywhere and once you're used to it it feels positively ancient to wait for money. When you're at a restaurant with friends you've already got their part of the bill on your account before you've paid the restaurant.

The end of the accounting search

Posted May 15, 2023 10:17 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

SEPA Instant is not universal. In some countries it seems like all the banks are SEPA Instant enabled (e.g. Germany and Nederland, perhaps?). In other countries, with stagnant and stultified banking markets, very few are - e.g. Ireland (I don't know of any retail banks in Ireland that have SEPA Instant!).

Even plain old SEPA still seems better than the US situation. SEPA is at least meant to clear within one working day.

The US seems to vary a lot. Wire transfers in the USA can be anything between instant to days. While ACH seems generally to be a working day. ???

The end of the accounting search

Posted May 16, 2023 1:42 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> While ACH seems generally to be a working day. ???

For transactions less than $5000 it's 1 working day. For anything else, it's _three_ business days.

There are plans to move to instant ACH transactions, but banks are dragging their feet because they like being able to charge fees for "instant" wire transfers (the largest banks in the US settle wire transfers within minutes).

Checks

Posted May 11, 2023 13:26 UTC (Thu) by corbet (editor, #1) [Link]

The US, that great leader in global financial innovation (or so I'm told) can be awfully slow sometimes.

We don't write a lot of checks anymore, but it does happen, and we still get payments that way too. The easy "send money to an IBAN" mechanism doesn't really exist here; we can do ACH transfers, but that requires a bit of setup and isn't often done for one-off or infrequent payments. Besides, in the wrong hands, a US rounting/account number pair can be used to do withdrawals as well, so naturally there are people who use them that way. So it is better to minimize the distribution of those numbers.

End result: we still have to deal in checks sometimes.

(Related story. Some years ago, when setting up the automated transfers to pay LWN's health insurance premium, I fat-fingered the account number. No checksum digit either on US account numbers. I realized the error soon after the first transfer had happened, but there was nothing I could do to reverse it, despite my attempts. It simply had to wait until the owner of the account I had mistakenly typed in noticed the significant chunk of money I had caused to be taken out of that account and protested.)

The end of the accounting search

Posted May 23, 2023 18:28 UTC (Tue) by fraggle (guest, #110846) [Link]

> Scheme looks like Lisp but isn't really Lisp

What a very silly thing to say.

3 year retrospective?

Posted Aug 21, 2026 4:20 UTC (Fri) by yodermk (guest, #3803) [Link]

I'd be pretty interested in hearing about how this has worked out over the last 3 years. Have any of the negatives been addressed by updates? Any regrets?

I'm planning to start a small software business, and hope to follow your lead in using GnuCash.