Towards a multi-purpose framework for tax-benefit microsimulation: Lessons from EUROMOD

Tax-benefit microsimulation models (MSMs) have been widely used in many countries for a number of years. Recently there has been interest in carrying out cross-country comparative exercises, examining the performance of policy instruments in different countries. Because of the limitations of national specific models in this regard (See Callan & Sutherland, 1997), an integrated multi-country model, EUROMOD, has been developed by a consortium of teams in 19 EU countries. This paper describes the generalised software framework used to construct EUROMOD.

Previous studies which have focused on the overall design of tax-benefit models have mainly focused on data- and broader design issues (Hoschka, 1986; Merz, 1991; Citro & Hanushek, 1991a, 1991b; Sutherland, 1995). Our paper aims to build on previous work by operationalising accepted concepts in terms of the detailed computational design of MSMs. In addition, it will also discuss entirely new aspects which only arise in building an integrated multi-country model.

To set the scene as to how a microsimulation framework should be created for tax-benefit modelling, it is useful to start by discussing the potential demands placed on the model. Broadly the objectives can be classified under the following headings:

• Flexibility;

• Ease of use;

• Robustness;

• Transparency and consistency of structure and concepts;

• Maintainability; and

• Cost effectiveness.

It is the role of tax-benefit models to assist in the analysis of existing and alternative policy scenarios. Depending on the purpose of the analysis, scenarios to be analysed will often need to satisfy a number of requirements such as revenue neutrality, improving work incentives, reducing poverty, etc. Because tax-benefit systems are highly non-linear with a large number of parameters, the list of possible constraints is literally endless (see, for example, Sutherland, 1991). It follows that the design of tax-benefit models should be flexible, enabling users to specify a wide range of different policy scenarios and make it easy to switch between scenarios. Hancock (1997) argues in a first analysis of the computing requirements for EUROMOD that flexibility is probably the most important corner stone of the computing strategy.

Although MSMs may in part be constructed by computer programmers, typical users will include economists, statisticians and social policy analysts in both academia and government. Ease of Use should ensure that all relevant features of the model are accessible to a wide range of users rather than just programmers. As a result, as much of the internal workings of the model should be accessible for users. At the same time, the complexity of the model should be organised hierarchically.⁴ In other words, it should be possible to use ‘basic’ features of the model without having to know all the details about more ‘complex’ model components. This ensures that the model is powerful while at the same time being useful for users with different backgrounds or different analyses in mind.

To enable users to make changes to tax-benefit algorithms in a relatively safe environment, one would ideally have a standardised set of pre-fabricated building blocks that can be adapted for specifying the algorithm of every possible tax-benefit instrument without any need for major reprogramming. Each element should be a derivative of a basic template and should have the same type of input and output data structures. Only the core algorithm which determines the behaviour of the element would need to be element specific. Once users have become familiar with this structure, they can then adapt any tax-benefit algorithm without having to ‘dig’ through program code. However, in general there exists a trade-off between flexibility and robustness. It is technically possible to develop highly flexible elements that, through parameterisation, can be used for many different purposes. For example, a generalised tax allowance that can be used to construct all types of tax-allowance used in different countries. However, a very large number of parameters which attempt to provide for any potential use of an instrument may result in a model that is both difficult to use and is more prone to produce errors through mis-specification of parameters. In the case of our example, it may result in a tax allowance module that is very long and difficult to follow.

Once accustomed to the operation of one country module, users of a multi-country model need to be able to access the parameters of other countries’ tax-benefit systems in a similar way. The multitude of necessary definitions and concepts (e.g., income taxes, fiscal units, sharing rules: see below) mean that consistent specification of relevant concepts across countries is essential. As highlighted in the previous section, simply lining up national models next to each other is not suitable as the design of national models will tend to reflect national priorities. Such conceptual differences will make it hard or impossible to compare the results of different models and prevent a consistent specification of policy reforms. A generalised modelling framework should therefore allow consistency in the specification of different systems. Given the fact that a typical tax-benefit system of one single country encompasses thousands of parameters, all of these parameters need to be readily accessible and organised in a transparent manner.

In order to be able to contribute to the debate of contemporary policy issues, tax-benefit models will need maintenance on a regular basis. In addition to frequent revisions of tax-benefit rules, underlying micro-data will need to be updated regularly so that model results continue to be based on representative data. The model framework should therefore be able to access and organise different data sets with ease. In addition, the complexity of tax-benefit systems make validation of the logical correctness of the model an essential component of any model building project. Finding and analysing discrepancies between model results and reference figures should be aided by a model structure which allows tax-benefit algorithms to be ‘traced’ in order to find any modelling errors. Similarly, it is important to break complex algorithms down into manageable pieces that can be analysed separately.

The development of microsimulation models is a resource intensive process, involving the construction of a software environment to handle the data, policy simulation and output routines, the transformation and matching of existing micro-datasets and translation of tax-benefit laws into a computational framework (McCrae, 1999). Another important expense is updating the model.

Repeating all these steps separately for each country multiplies costs, while re-using one single microsimulation framework for different countries or purposes can be a very cost-effective method of building new models.

A general tax-benefit modelling framework will ideally be able to accommodate any existing or hypothetical tax-benefit system. In designing such a framework it is therefore essential to identify the principal elements of tax-benefit systems. In other words, it is necessary to find a suitable ‘common denominator’ of all (reasonably) possible structures. However, in general, there exists a trade-off between structure and flexibility: The modelling framework needs to provide the structure necessary for setting up a simulation model without limiting the breadth of tax-benefit systems that can be simulated.

In ‘real world’ tax-benefit systems, elementary policy rules are grouped together to form identifiable blocks such as ‘instruments’ (e.g., a tax credit), ‘policies’ (e.g., income tax), etc. In modelling a country’s system, it is desirable to match the real system’s hierarchy as closely as possible so that the logical representation provides a good intuitive equivalent of the original. From a model construction point of view it is desirable to try to generalise this representation as much as possible, so that most national systems can be described utilising the same structure.

Figure 1 shows the hierarchical structure that we use for a general tax-benefit modelling framework and introduces the terminology used in the remainder of this paper. Each tax-benefit system is made up of individual policies. These are elementary collections of tax-benefit instruments. Examples for a policy are Income Tax, Social Insurance Contributions or Social Assistance Benefits. The policy spine is a list of policies indicating the sequence by which they are applied in the tax-benefit system. For example, if social insurance contributions are tax deductible, then the entry Social Insurance Contributions would have to appear before Income Tax because the model requires the amount of social insurance contributions as a prerequisite for calculating income tax; similarly, if social assistance benefits depend on after tax income, then the entry Social Assistance Benefits would have to appear after Income Tax since income taxes would be a necessary input for calculating Social Assistance. At the lowest level is the tax-benefit module, which performs the calculation of a certain part of the tax or benefit (e.g., a deduction, or applying a rate schedule to a tax base) on each fiscal unit. The modules represent the elementary building blocks of the tax-benefit system: only the modules contain actual tax-benefit rules. All other levels are merely necessary to structure these rules and to apply them in the appropriate sequence.

Figure 1

Download asset Open asset

The tax-benefit structure that we have just described is linearly sequential. However in certain cases a decision must be made between a range of choices. For example a fiscal unit may be entitled to a range of different benefits and must choose one; or, as in the case of optional joint taxation, individuals may have to choose between being taxed individually and pooling income to form a joint tax base. Similarly, behavioural reactions to policy change are best modelled as an optimisation over a range of alternative decisions. The framework allows for such typologies by providing decision-rule elements. If required, these can be inserted anywhere along the policy spine to construct necessary ‘branches’ of a decision.

In terms of the actual computing environment, the MSM framework itself has been implemented as follows. In choosing the environment and programming language for the model framework, an effort has been made to ensure its longevity by not irrevocably attaching it to one specific computing environment. In addition, the aim has been to use software of a type that is familiar to potential users as well as easily available. However, care has been taken to avoid a rigidity, which would prevent future adaptations to other platforms such as UNIX.

The programming language used is C/C++ (Microsoft Visual C++). This facilitates efficiency in programming. However, the ability of C/C++ to write very streamlined and “direct” algorithms sometimes reduces the readability and transparency for less experienced users. As a rule, where trade-offs existed between transparency and speed, we accepted decreases in the model’s speed in return for improved readability and usability.

By using a method for database access (ODBC) which is available for all major relational database management systems, database systems other than the one used as a default can be used for data storage and management. Both the input micro-data and the model’s micro-output (simulation results) can be stored in one of the widely used relational database systems (Oracle, Microsoft SQL, etc.) Microsoft Access is used as the default. Input and output data are stored in two separate databases. In this way, the input micro-data can remain “read-only”. However, the relational data structure makes it possible to combine the physically separate input and output data into one logical table to analyse the impact of a tax-benefit system in relation to all sorts of characteristics (age, household size, etc.).

All parameter lists are stored as spreadsheet tables and can be read and manipulated with any spreadsheet software (e.g. Microsoft Excel).

In order to accommodate the numerous requirements and different uses outlined in Section 2 and to ‘fill’ the individual boxes of the hierarchy described in Section 3 with actual tax-benefit algorithms, the modelling framework will necessarily need to be quite generalised. The degree of generalisation relates to the degree to which a model is ‘parameterised’ so that model code can be used for different purposes without re-coding. For instance, a ‘tax-schedule’ module that is programmed in a way that works with any number of tax bands and any set of tax-rates can be re-used for modelling the income tax system of many different countries. While generalising as much as possible makes the model more flexible, it also has the effect of making it more difficult to develop and also potentially less transparent, conceptually and computationally more complex (and, hence, slower) than a similar model which is built for a narrow and a priori clearly defined set of applications.

As briefly mentioned above, designing any MSM framework is a very resource intensive task. In a survey by Mot (1992), it was found that static national models generally took 2 to 3 man-years to develop. More sophisticated models, such as the TRIM2 model in the USA, took much longer. Although more costly to build initially, a generalised model is less costly in the long run if the framework can be re-used for a multitude of purposes. In addition, the robustness and reliability of a modelling framework will be positively related to the number of users and uses. As a result, a generalised modelling platform will ‘mature’ more quickly than purpose-built model frameworks with a more narrowly defined scope. A generalised multi-purpose framework will also facilitate communication and co-operation between researchers and reduce training costs as many people will share similar experiences and problems.

The use of parameterisation aids all the primary objectives of a generalised framework outlined in Section 2. Modelling flexibility can be achieved by enabling the user to make adaptations and definitions without changing the program code itself, making changes instead to certain sets of parameters. As a result, the specification of policy reform scenarios becomes easier. The parameterisation of tax-benefit algorithm also ensures that their operation remains transparent and adaptable which in turn make the model more robust. Similarly, model maintenance is considerably simplified if all one needs to do to update policy rules is to change the relevant parameters (such as new amounts, rates or definitions). Parameterising common model elements which can be used in many different contexts also aids consistency and transparency. An example is the generalised social benefit routines described below.

Parameterisation also facilitates experiments with different parameter values. For example, one may wish to analyse how including unemployment benefits in the income tax base, changing the definition of the fiscal unit (e.g., changing the maximum age at which a person is considered a ‘child’ for the purpose of computing a certain benefit), or altering the number of tax brackets affect the distribution of disposable income. In the present framework, all such changes can be specified by setting appropriate parameters in the parameter lists. The actual tax-benefit algorithms are coded as functions of these externally defined parameters and will not normally have to be accessed by the model user.

The key elements of the tax-benefit framework that are parameterised are:

1. Modules, the primary building blocks of the model. Components to be parameterised include the definition of parameters directly related to the tax-benefit algorithm relevant for each module (e.g., rates, bands thresholds, type of income concepts, fiscal units).

2. Policies and Policy Spine, the structuring mechanism within the framework. The parameters relate to the types of module/policy (i.e., which modules make up a policy and which policies make up the tax-benefit system) as well as their order.

3. The definition of the fiscal units relevant for an instrument (e.g., who belongs to a ‘family’ receiving the instrument, who belong to a ‘couple’ whose income is taxed jointly, who counts as a ‘child’ for the purpose of computing child benefits).

4. The definition of sharing rules within the unit (i.e., which unit member receives what part of a benefit and how are tax burdens shared between members of the tax unit).

5. The definition of aggregate income concepts that combine income variables used either by an instrument (e.g., ‘taxable income’ such as market incomes plus benefits minus deductions and allowances) or as an output of the model (e.g., ‘disposable income’).

6. The set of variables to be used in the framework as well as their characteristics such as whether they are to be simulated (e.g., taxes) or read from the data (e.g., employment income) or whether they are monetary variables.

7. ‘Uprating’ factors for each monetary variable, used for updating purposes. If the data was collected in 1996 and the policy we wish to examine is for 1998, then we need to alter the data to bring all monetary variables forward to 1998 (accounting, e.g., for inflation, earnings growth, etc.).

8. Output functions, including the variables to be written to the output file, as well as the types of summary statistics required as output.

In the following section we describe the implementation of these key concepts and elements of MSMs in more detail.

In the previous section, we have alluded to a number of different concepts such as ‘modules’. ‘fiscal units’, ‘sharing rules’, ‘income concepts’ and ‘common routines’. In this section, we shall discuss the actual implementation of these elements in the MSM framework.

5.1 Modules

The concept of modules as distinct building-blocks of the simulation has special advantages. By using the same building blocks for different tax-benefit systems, one can build up a large ‘library’ of national specific modules. It is therefore possible to select modules from this library when either designing a new system or examining the effect of introducing aspects of other systems in a given country. The flexible order of modules and the high degree of parameterisation ensure that the same modules can be used for a multitude of different purposes.

In terms of the actual implementation, there a number of desirable features. The structure of the module should be a function with clearly defined inputs and outputs. The body of the function should look similar for each tax-benefit instrument. Every section should be clearly labelled and documented so that users wishing to adapt an existing instrument would readily see where changes have to be made while those wishing to implement a new instrument would only have to fill in the blank spaces. It should be possible to freely define intuitive variable names used in the algorithm to make interpretation as straightforward as possible.

Figure 2 describes the general structure of modules as implemented in the framework. The inward arrows define the set of input variables. Before the actual tax-benefit algorithm coded into the module is initiated, each module performs several steps. The first step involves determination of the relevant fiscal unit such as individual household or family etc. that the instrument applies to. The next step involves reading the parameters such as rates, bands thresholds, age limits etc. used by the algorithm. Other parameters include the definitions of aggregate income concepts used within the module such as earnings, total benefits and tax-base. Once these parameters have been read, the actual calculations take place.

Figure 2

Download asset Open asset

To minimise the scope for errors and interference with other parts of the model, each module should only contain those parts of the program code, which are absolutely necessary for specifying the algorithm. Everything else should be “hidden” from the user.⁵ Applying this design philosophy ensures that individual modules can be developed independently and thus the operation of one module does not interact with the operation of other modules. This improves the robustness of model, so that errors in one part of the code do not influence other parts. Once a module has been thoroughly tested and is found to work, it can be added to the system as a whole. This is a method also employed to varying degrees by the US model TRIM2 (Mot, 1992) and the Institute for Fiscal Studies model, TAXBEN (Giles & McCrae, 1995). Equally important, a strictly modular design simplifies the maintenance of a model considerably. It ensures that changes, which inevitably have to be made during the lifetime of any tax-benefit model, do not have unexpected side effects on other modules and enables separate parts of a MSM to be developed independently by different members of a team. For the development of EUROMOD, this has been a critical feature since the implementation of 19 tax-benefit systems cannot be completed by one person alone.

In order to support safe and efficient implementation of new instruments, the MSM framework provides a large number of frequently used standard functions. These are routines that perform operations or determine characteristics which are relevant for the calculation of a large number of policy instruments (e.g., NumberChildrenInTaxunit, IsMarried, IsLone Parent). This approach ensures a consistent interpretation of variable values (especially categorical variables, such as marital status) across all modules, considerably simplifies the maintenance of the model and means that users do not have to access variables in the microdata directly.

Table 1 illustrates typical module parameter sheets. Each module starts with the name of the module (co_it_main_tfa; co_it_ schedule) followed by a number of parameters. Parameters common to each module are TAX_UNIT and SWITCH. The former specifies the fiscal unit relevant for this module while the latter determines whether or not this module should be included in the calculations. All other parameters are module-specific (i.e., they depend on the specific tax-benefit algorithm coded into the module).

Table 1

param_no param_name	Period first_system UK_1998 end_system
first_module		Income Tax
…
co_it_main_tfa
1 tfa	y	4,195
2 age_limit1		0
3 age_limit2		64
4 TAX_UNIT		individual
5 SWITCH		1
co_it_schedule
1 nbands		3
2 tax_band1	y	4,300
3 tax_band2	y	27,100
4 tax_rate1		0.2
5 tax_rate2		0.23
6 tax_rate3		0.4
7 Tacabley_il		TaxBase
8 TAX_UNIT		individual
9 SWITCH		1
…
end_module

In addition to modules that have been designed for a specific purpose in a specific country the framework also provides a large number of common modules, which were designed without any single country or use in mind. Instead they can be used for many different purposes. Examples are schedules where the number of rates or other parameters is flexible and where the income base to which the schedule is to be applied can be freely defined (e.g., co_it_schedule in Table 1). All these parameters can be specified in parameter sheets, which means that in many cases, even very complicated instruments can be implemented without any need for programming. Apart from the considerable amount of time and effort that can be saved by re-using already existing building blocks, there is, again, the added advantage that these general modules have already been thoroughly tested. One can therefore be confident that the risk of programming errors is minimal.

Because for many countries, the sub-components of social benefits can be classified in a similar manner across countries, it is possible to classify benefits into a number of common modules, resulting in one of the most powerful set of common modules in the framework. Eligibility is determined first. If a unit is eligible for the benefit then their ‘means’ (i.e., the income that is set against a benefit) are calculated.⁶ Next we specify the ‘equivalence scale’ for determining the benefit amount as a function of characteristics of the fiscal unit (such as age, number of people in the family and number of children). By imposing a common structure on seemingly often very different benefits, it also allows for the relative generosity of benefits for different family types to be easily compared across countries without having to adjust for currency differences. Finally, the majority of all benefits in western countries can be classified as the base amount times the equivalence scale minus means times a withdrawal rate (r).

Both eligibility and equivalence scale modules contain large numbers of different types of parameters to permit modelling of many different types of benefits and reforms. A list of parameters that exist in the framework and can be used for specifying eligibility conditions and equivalence scales is provided in appendix 2 of Immervoll and O’Donoghue (2001a). In total, one can chose between more than 1000 possible parameters. Because such a large number of parameters would be extremely difficult to manage, we allow the user to select only the parameters they wish to use, ignoring the rest. The parameters can therefore be seen as a library of possible conditions to determine eligibility and equivalence scales. All eligibility conditions can be combined using a combination of logical AND, OR and NOT operators as described in the appendix of Immervoll and O’Donoghue (2001a). In constructing EUROMOD, we were able to implement almost all benefit instruments that existed in the EU using the common modules described here.

This paper describes the rationale for microsimulation tax-benefit modelling and the demands placed on the method by users. We note the high cost of developing microsimulation models in different countries and argue for the need to control these costs. We present a generalised microsimulation framework that, if adopted, provides substantial economies of scale in the design of microsimulation models. Although the time taken to construct this general framework has been considerable, the subsequent economies of scale that result have already become evident as the framework and its components have successfully been used to implement an integrated European tax-benefit model comprising the tax-benefit systems of 19 EU member countries. This implementation has taken three years whereas a separate development of individual country specific MSMs would have taken much longer.⁹

The principal design feature of the generalised framework is the extent to which routines and operations have been generalised and parameterised and are thus re-usable for different purposes. Examples not typically found in national specific tax-benefit microsimulation models include the consistent parameterisation of:

• The fiscal unit of analysis;

• The order in which instruments are simulated;

• Income concepts; and

• The input database and related operations such as data updating, etc.

The use of encapsulated policy components makes resulting tax-benefit models flexible and robust. It also allows users to focus on those parts of the tax-benefit system which are of interest for the research question at hand while not having to worry about computational details of the modelling framework as a whole.

A frequent criticism of static microsimulation modelling is that it only measures the day-after effect while some reforms may initiate relevant behavioural responses such as reduced work effort. While incorporating behavioural changes can be a worthwhile exercise, its usefulness depends on the questions to be addressed. For example, for the purpose of understanding the interactions between different tax-benefit instruments a model, which does not mix immediate effects with longer-term behavioural dimensions, will often be preferable. Nevertheless, because of the framework, future expansions of the model to incorporate behavioural response are feasible without radical redesign. For example Colombino et al. (2008) introduced a module that called the tax-benefit system in EUROMOD to generate a budget set required to estimate a labour supply model in a number of EU countries.

1. 1
   The impact of means tested assistance in Southern Europe. EUROMOD Working Paper 6/01

   1. JL Albuquerque
   2. O Bargain
   3. M Baldini

   et al. (2001)

   Department of Applied Economics, University of Cambridge.

   • Google Scholar
2. 2
   What do we learn about tax reform from international comparisons? France and Britain

   1. AB Atkinson
   2. F Bourguignon
   3. P-A Chiappori

   (1988)

   European Economic Review 32:343–352.

   • Google Scholar
3. 3
   Microsimulation of social policy in the European Union: Case Study of a European Minimum Pension

   1. AB Atkinson
   2. F Bourguignon
   3. C O’Donoghue

   et al. (2002)

   Economica 69:229–243.

   • Google Scholar
4. 4
   Eur3: a prototype European tax-benefit model. Microsimulation Unit Discussion Paper No. 9703

   1. F Bourguignon
   2. C O’Donoghue
   3. J Sastre-Descals

   et al. (1997)

   Cambridge: Department of Applied Economics.

   • Google Scholar
5. 5
   Simulating welfare and income tax changes: the ESRI tax-benefit model

   1. T Callan
   2. C O’Donoghue
   3. C O’Neill

   (1996)

   Dublin: The Economic and Social Research Institute.

   • Google Scholar
6. 6
   The impact of comparable policies in European countries: microsimulation approaches

   1. T Callan
   2. H Sutherland

   (1997)

   European Economic Review 41:627–633.

   • Google Scholar
7. 7
   The uses of microsimulation modelling, Volume 1, Review and Recommendations

   1. CF Citro
   2. EA Hanushek

   (editors) (1991a)

   Washington: National Academy Press.

   • Google Scholar
8. 8
   The uses of microsimulation modelling

   (1991)

   The uses of microsimulation modelling, 2, Technical Papers, Washington, National Academy Press.

   • Google Scholar
9. 9
   Behavioural and welfare effects of basic income policies: a simulation for European countries. CHILD – Centre for Household, Income. Labour and Demographic Economics Working Papers, wp03_08

   1. U Colombino
   2. M Locatelli
   3. E Narazani

   et al. (2008)

   Dept. of Economics, University of Turin.

   • Google Scholar
10. 10
    The IFS micro-simulation tax and benefit model. IFS Working Paper W95/19

    1. C Giles
    2. J McCrae

    (1995)

    London: Institute for Fiscal Studies.

    • Google Scholar
11. 11
    Computing strategy for a European tax-benefit model. Microsimulation Unit Discussion Paper MU9704

    1. R Hancock

    (1997)

    Department of Applied Economics, University of Cambridge.

    • Google Scholar
12. 12
    Microanalytic Simulation Models to Support Social and Financial Policy

    1. P Hoshka

    (1986)

    Requisite research on methods and tools for microanalytic simulation models, Microanalytic Simulation Models to Support Social and Financial Policy, Amsterdam, North-Holland.

    • Google Scholar
13. 13
    Fiscal drag - an automatic stabiliser?

    1. H Immervoll

    (2000)

    Paper presented at the 56th Congress of the International Institute of Public Finance.

    • Google Scholar
14. 14
    Welfare benefits and work incentives: the distribution of net replacement rates in Europe. EUROMOD Working Paper 4/01

    1. H Immervoll
    2. C O’Donoghue

    (2001a)

    Department of Applied Economics, University of Cambridge.

    • Google Scholar
15. 15
    Net to Gross. EUROMOD Working Paper 1/01

    1. H Immervoll
    2. C O’Donoghue

    (2001b)

    Department of Applied Economics, University of Cambridge.

    • Google Scholar
16. 16
    An introduction to EUROMOD. EUROMOD Working Paper 0/99

    1. H Immervoll
    2. C O’Donoghue
    3. H Sutherland

    (1999)

    Department of Applied Economics, University of Cambridge.

    • Google Scholar
17. 17
    The development and uses of tax and benefit simulation models

    1. J McCrae

    (1999)

    Brazilian Electronic Journal of Economics, 2, 1.

    • Google Scholar
18. 18
    Microsimulation - a survey of principles, developments and applications

    1. J Merz

    (1991)

    International Journal of Forecasting 7:77–104.

    • Google Scholar
19. 19
    Survey of microsimulation models

    1. ES Mot

    (1992)

    The Hague: VUGA.

    • Google Scholar
20. 20
    For richer, for poorer?: The treatment of marriage and the family in European income tax systems

    1. C O’Donoghue
    2. H Sutherland

    (1999)

    Cambridge Journal of Economics 23:565–598.

    • Google Scholar
21. 21
    How effective is the British government’s attempt to reduce child poverty? CASE paper 38

    1. D Piachaud
    2. H Sutherland

    (2000)

    CASE, London School of Economics.

    • Google Scholar
22. 22
    The arithmetic of tax and social security reform: A user’s guide to microsimulation methods and analysis

    1. G Redmond
    2. H Sutherland
    3. M Wilson

    (1998)

    Cambridge: CUP.

    • Google Scholar
23. 23
    Constructing a tax-benefit model: what advice can one give?

    1. H Sutherland

    (1991)

    Review of Income and Wealth 37:199–219.

    • Google Scholar
24. 24
    Static microsimulation models in Europe: A survey. Microsimulation Unit Discussion Paper, MU9503

    1. H Sutherland

    (1995)

    Cambridge: Department of Applied Economics.

    • Google Scholar
25. 25
    An introduction to Object-Oriented Programming and C++

    1. RS Wiener
    2. LJ Pinson

    (1988)

    New York: Addison-Wesley Publishing.

    • Google Scholar
26. 26
    Income data collection in international household surveys

    1. DH Weinberg

    (1999)

    Paper presented at the 3rd Meeting of the Canberra Group in Ottawa.

    • Google Scholar

Author details

1. Herwig Immervoll

   Social Policy Division OECD, France

   For correspondence

   herwig.immervoll@oecd.org

2. Cathal O’Donoghue

   Rural Economy Research Centre Teagasc, National University of Ireland, Ireland

   For correspondence

   Cathal.ODonoghue@teagasc.ie