A New Tax System: In Practice

Previously I wrote about the theory of a simple tax system. This time I’ll talk about the practical details and provide examples of the transactions to which the tax system can apply. It’s simple so there aren’t a lot of them.

The Implementation

The government would maintain a simple but large database looking a little like the following table. It contains examples of a D-Factor from each range defined in the previous post:


Product Type/Category


Fresh unprocessed food, water, medical care, etc.


Wind generated electricity

Fuel (Sustainable)



Fuel (Sustainable)


Financial Loans




Cigarettes, reality TV


Coal generated electricity

Fuel (non-sustainable)


Alcoholic beverages


Processed food


Train, bus, tram

Public Transport



Public Transport



Public Transport




Charity donations


Human powered bicycle


Health Insurance


Specific medicine

Expensive medicines (PBS)

Necessarily large negative

The column titled “Product Type/Category” covers a broad range of similar products with a common D-Factor. Specific products listed under the Products column may have a D-Factor different to its parent category. This field will usually be blank except in the case where a specific product or service in a category may require a different D-Factor.

Businesses and other tax payers would access the database via the internet to keep synchronised with the latest D-Factors in order to charge the correct tax rate at any time (D-Factors may change. More on that later). Cash payment systems could be always online or, if necessary, work offline and alert users (eg. shop owners) when the local D-Factor records become out of date beyond a configurable time limit. D-Factors would be displayed at the point of sale for retailers and published as appropriate for all other types of tax payers. Everyone could essentially look up any product or type to see the current D-Factor. No doubt there will be a variety of mobile device apps to provide live cost calculators.

Invoicing systems would be required to record the D-Factors of any particular date in order to charge correctly.

The Tax Collector

One small issue is who acts as tax collector. It could be either party. In practice the answer is probably the entity most equipped to do so and that would be the business, in the case of standard consumer-business transactions. Similar to how it currently works. For business-business transactions, it would likely be the entity that ends up with the money at the end of the day. Again, same as the current system.

Having said that, this model will make no distinction between either party in any transaction. An individual buying bread and milk is the same as the supermarket for tax purposes. Same as the employee/employer relationship. Services go one way, money goes the other, tax goes to the government.

Variations to D-Factor

The above table is obviously very simplistic. In reality it should allow for changes to the D-Factor, either on an individual product basis or category basis and also for smooth changes from one set of D-Factors to another over a period of time. It should allow the D-Factors for different products and categories to smoothly change over different periods during a change-over.

There shall be provisions for pre-sets of D-Factors that favour different aspects of the economy. For example, pre-sets for industry, community, family, environment, etc.


With today’s ubiquitous connectivity there should be no reason why businesses cannot periodically download relevant sections of the D-Factor database to keep their total tax-inclusive prices up to date. Or even operate live. These D-Factors would be widely available for public perusal. Even for variable D-Factors within, say, a transition period, D-Factors would always be up to date and people would know exactly what to pay for things.

Restrictions and security

Of course, a tax system that provides such ease of modification needs some sort of protection against willy-nilly changes. Changes to any D-Factor (or the G value for that matter) would still have to go through parliament. From a technical point of view there would be levels of authorisation and checking in place to verify that any attempted changes are logged and audit-able.

If the database is to be publicly accessible it will require security features equivalent to the best the IT security industry can offer, in the same way sensitive data is managed elsewhere today.

In the next instalment I will talk about transitioning from the old system to the new.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s