Creating Non-US Tax Reports

Bob Gustafson bobgus at
Thu Jan 30 18:34:36 EST 2014

On 01/29/2014 11:41 AM, Alex Aycinena wrote:
>> ---------- Forwarded message ----------
>> From: "Clint Redwood" <clint at>
>> To: "gnucash-devel at" <gnucash-devel at>
>> Cc:
>> Date: Wed, 29 Jan 2014 16:29:03 +0000
>> Subject: Creating Non-US Tax Reports
>> Hi!
>> Apologies if this has been done to death but googling found nothing
>> relevant.
>> Is there any way of setting up custom tax codes against accounts, and to
>> use the tax reports to do UK personal and corporation tax. It doesn't
>> appear to be able to be done inside the application but I wondered if there
>> is a configuration file I could modify to enable me to use this report
>> effectively, rather than just showing US forms and boxes. Clearly the
>> export isn't going to be relevant, but just having the report would be
>> useful.
>> Any suggestions or pointers welcome.
>> Thanks!
>> Yours,
>> Clint Redwood
>> Screwtape Limited, Registered 06663232, Babington House, 26 College Road,
>> Chilwell, Nottingham NG9 4AS
>> There is no easy way to use the existing US-based report for non-US income
> tax reporting. Of course it can be done with a bunch of re-programming.
> I maintain this part of gnucash and plan in the future to make changes that
> actually would allow this. For the US, since the current system is based on
> 'txf' codes, the maintenance of which is dormant, the system is gradually
> getting stale; I would like to make the 'txf' code not the key but an
> attribute of a hidden key so that new codes could be added even if no
> 'txf'' code exists for an item. If I do this in a fairly generalized way,
> then it could be used to support multiple taxing jurisdictions (within the
> US and outside of the US) simultaneously. If in an even more generalized
> way, it could support user-managed tagging of accounts, transactions, and
> splits, a feature which has also been asked for and I would like to use
> personally. But this will take a bit of effort and time to accomplish.
> Alex
Thanks much for your effort and future efforts.

Perhaps if you started with the idea of a user-managed tagging of 
accounts, transactions, and splits - it would be flexible enough to be 
useful without a lot of extra user keyboard effort.

I myself don't yet use GnuCash, but I would like to use it to centralize 
the storage of my (minimal) keystrokes and and be able to generate 
useful reports. My records are in various bank on-line bill paying 
systems that don't really record what I would like to record (such as 
the actual payee and why). If I dump these bank records (US banks), I 
only get 'CHECK 2014', '20.47'. Pretty dismal.

Many years ago, I was quite happy with Quicken for the Mac. Using the 
Checkfree feature, I could pay my bills and have good data stored on my 
own computer. But Quicken for the Mac has been gutted by Intuit and 
somehow the bill pay feature doesn't work the same way. Until recently, 
I was writing out checks by hand and mailing them.

I do have records downloaded from German accounts that are wonderful in 
their completeness (MT940 in UTF-8 character set). I process these using 
a program developed over a number of years. The key feature is a set of 
patterns which categorize all of the transactions. The MT940 files also 
have enough redundancy to give me some confidence in my own program. My 
balance equals the bank balance regularly over the past couple of years.

The categorization patterns require maintenance as the bank changes 
their standards over the years - the character set was only recently 
standardized on utf-8. Also, even though umlauts are possible in the 
character set (and my patterns..) the bank has recently chosen to use 
'UE' instead of the u with two dots over it. Thus my collection of 
patterns has many umlaut variations (as well as detecting infrequent 
mispelled data). The pattern file is currently 495 lines long. Bank data 
stretches back to 2006.

If your user-managed tagging could incorporate user-written regular 
expression patterns, I think it could go a long way toward satisfying a 
big range of GnuCash users.

Best regards

Bob G

More information about the gnucash-devel mailing list