What are the units for Eora?

Eora is in current year '000 USD. The satellite accounts are in physical units, which are specified in the labels/metadata.

Where I can read more about Eora?

The main paper describing Eora is:

Lenzen M, Kanemoto K; Moran D, and Geschke A (2012) Mapping the structure of the world economy. Environmental Science & Technology 46(15) pp 8374–8381. DOI: 10.1021/es300171x

This paper provides a gentler introduction:

Lenzen, M., Moran, D., Kanemoto, K., Geschke, A. (2013) Building Eora: A Global Multi-regional Input-Output Database at High Country and Sector Resolution. Economic Systems Research, 25:1, 20-49, DOI:10.1080/09535314.2013.769938

How should I cite Eora?

If you just use the MRIO, we recommend you cite the following two Eora construction papers:

Lenzen M, Kanemoto K; Moran D, and Geschke A (2012) Mapping the structure of the world economy. Environmental Science & Technology 46(15) pp 8374–8381. DOI: 10.1021/es300171x

This paper provides a gentler introduction:

Lenzen, M., Moran, D., Kanemoto, K., Geschke, A. (2013) Building Eora: A Global Multi-regional Input-Output Database at High Country and Sector Resolution. Economic Systems Research, 25:1, 20-49, DOI:10.1080/09535314.2013.769938

If you also want to use the environmental indicators of Eora, we recommend you cite the following papers:

How do I read .spbin files?

Previously we provided many files in the Eora-specific .spbin file format (optimized for sparse and large matrices). Now, we provide most files as comma-delimited .csv, tab-delimited .txt (these can be opened in Excel), or .mat (which can be read in Matlab, Octave, Python, and R). To read .spbin files you can use our binread.m or binread.py scripts.

How did you get an IO table for [country X] when the country doesn't publish a table?

The Eora database contains MRIO tables from the national statistics offices of all countries who create them. For the other countries, for which there is no official IO table (e.g. Tunisia) we start with a 26-sector proxy IO table combining diverse industries and products from the Australian, US, UK and Japanese economies, then scale it to match the available data that for that country, such as GDP, GNE, imports bundle, exports bundle, and the like. We have experimented with several different methods for estimating this proxy table (e.g. using import mixes, neighboring countries, export mixes) but, for the time being, have settled on the template proxy table method since it is relatively simple, robust, and defensible method. The optimization process used to build Eora then overlays the trade and macroeconomic data available onto that template table, enforces balancing, and reconciles conflicting data, in order to produce an estimated Tunesian IO table.

What is your data source for [X]?

The Supplementary Information for the "Mapping the Structure" paper is the primary document describing the Eora data sources.

The Data Sources report CSV files available on the website describe which data sources (also called constraints) are involved in the creation of each section of the MRIO.

The process of creating Eora employs pro-rating, concordances matrices, and interpolation, so it can be that we provide results that are not published by any primary data provider. For example, Eora may contain a sectorwise GHG emissions inventory that has been constructed by pro-rating a single data point (total GHG emissions) across the sectors in that country, using GDP as a proxy.

The IO table for developing country X appears to have errors

The goal of Eora is to to make a consistent global model. When smaller or developing economies have inconsistent or missing data the tables for these countries can become distorted during the process of building a consistent global model. These problems can be identified using the Table Balancing Check reports. In some cases countries raw macroeonomic data is highly unreliable or conflicting. This can occur especially during periods of war, government transition, or hyperinflation. Eora is built by combining and reconciling various data sources, but these processes are purely algorithmic; there is no manual intervention in the raw data. Thus missing, incomplete, and conflicting raw data can mean that we are unable to realize a consistent, balanced, IO table for a country in a given year.

The Eora database is being continually updated, taking into account revised statistics published later by data providers. We strive to provide consistent IO tables for all countries.

What do negative values mean?

In general negative values should only be allowable in the Change in Inventory (CII) column of Final Demand, and in the trade, transport, taxes, subsidies, and Purchasers Price sheets (since Purchasers Price is Basic Price plus trade, transport, taxes, and subsidies, large values in the margins can transform a >0 value in the Basic Price to a negative value in the Purchasers Price; this is conceptually legitimate but in practice is usually a result of errors or bad values in the Margins sheets). In the Margins sheets, negative values mean that that transaction in that margin resulted in a loss of value. Such value-decreasing transactions may be mirrored by value-adding transactions in other sectors. Negative CII means that part of the sector’s gross output was supplied by a drawdown of existing inventory. Large negative CII values can introduce other problems, including that the sector’s gross output (row sum) becomes negative, and <0 values in Xout will then introduce <0 values in A and L in a Leontief model. Negative CII values are legitimate, however in many cases they can also be erroneously introduced or amplified during the optimization and balancing process. Since CII values are poorly constrained during matrix balancing the optimizer may resolve imbalanced sectors by adding value to the CII column. We are aware of this issue and take steps to prevent it, but there is currently no known prefect solution. Negative values should not occur in the IO tables or Value Added blocks of Eora. In rare cases negative values are allowed in the satellite accounts, e.g. for land use change. In general negative values should be avoided by replacing a single record which contains mixed positive and negative values (e.g. “forest cover change) with two more clearly defined records that contain only positive values (e.g “forest cover increase”, and “forest cover loss”).

One way to handle negative CII values is to remove any negative CII values from Final Demand, by setting them to zero and introduce a new row in the Value Added block labeled “supply from inventory” containing mirrored positive values for the affected sectors. In MATLAB pseudocode this would be:

CII = zeros(size(Y));    % Temporary matrix to hold CII values
CII(Y<0) = Y(Y<0);       % Record negative CII values
Y(Y<0)=0;                % Set negative CII values to 0 in Y
CII = sum(-CII’,)1;      % Transpose, multiply by -1, and flatten to a single row
V = horzcat(V, CII);     % Append the new CII row to the value added block

Since negative CII values are generally small and occur in small sectors, depending on the application it may be safe to ignore them. For global scale analysis or analysis of major economies, the results are generally not significantly affected by setting negative CII values to 0. It is recommended to test the influence of negative values on your results before accepting this shortcut solution.

Why isn't Eora perfectly balanced?

We try to achieve balanced tables but sometimes this is impossible. An optimizer attempts to find an optimal balanced MRIO that best satisfies conflicting data and is balanced. But it cannot always reconcile all the conflicts. So, for some sectors in imbalance remains. Generally this imbalance is small, e.g. <5% for bigger economies, but can be up to 20% (IIRC) in the worst case sectors, e.g. Manufactured Goods from Mongolia, or similar sectors where we have poor or conflicting input data.

The Rest of World sector is introduced to absorb these imbalances.

You can see the national ratios of Gross National Expenditure + exports versus Gross Domestic Product + imports on the country quality reports page. Under ideal balancing this ratio should be 1. Note however that data on countrywise total exports and imports fundamentally conflict with global trade balances. One cannot achieve a balanced global multi-region input-output table whilst at the same time respecting data on exports and imports. This means that in a real MRIO table, either balancing conditions must be violated or raw data mis-represented. The current Eora tables have been constructed with emphasis on fulfilling balancing conditions predominantly for large countries. Hence, balancing conditions are usually very well met (1% imbalance) for large economies such as the USA, Japan, China and Germany, but less well met for either small countries, or countries where international trade is larger than GDP (up to 50% imbalance for example for São Tomé & Principe, Singapore and Hong Kong).

The Eora26 sectorwise balancing may be slightly worse than the full Eora balancing. To generate Eora26, the step of converting SUT tables to IO tables involves both a loss of information and the injection of new assumptions. That's why we provide Eora26 as-is. We concentrate our efforts on the full Eora model and hence do not provide QA results for Eora26. Overall, we expect the Eora26 results to be similar to, or slightly lower quality than, the full Eora results.

Eora26 is provided for ease of use. The full Eora table, with its heterogenous structure, can be more challenging to use but provides the highest quality results. We are happy to collaborate on research projects where we can handle the MRIO work and provide you digested results for your research question.

Balancing is not required for the basic price sheet alone, since product taxes and subsidies must be added into the balance. The balancing constraint is therefore applied over the basic-price sheet plus taxes on products minus subsidies on products. Margins 2 and 3 (trade and transport) sum to 0 column-wise, so you can exclude these. In pseudocode, the balancing condition is:

M = M_0; % Margin 0 basic price
M_2; % trade margin
M_3; % transport margin 
xout = sum(M,2); % Row-wise sums
M_all = M_0 + M_2 + M_3;
xin = sum(M_all,1);   %column sums
xout(1) / xin(1)   % this should be 1.0 (perfect balance)

I found an error in Eora. How I can report it / have it fixed?

We know that Eora is not perfect and that some errors remain. We think that overall, for global totals and most countries, the results are suitable for publications, but for individual sectors, and some country-years, there are bad results. The AISHA software used to create Eora provides lists of top conflicting data and imbalanced sectors and we use this, along with publication and project based needs, to determine which bugs we work on next.

A unique feature of Eora is that each value is reported along with an estimation of its standard error.

You may report errors to info@worldmrio.com

What are re-exports/re-imports?

This is well-defined at the UN Stats page on the topic. They write, "Exports of a country can be distinguished as exports of domestic goods and exports of foreign goods. The second class is generally referred to as re-exports. ...Re-imports are goods imported in the same state as previously exported."

How is the number of sectors in each table determined?

We use the economic classification provided by each national statistical office. This allows us to retain the best data quality since we minimally disturb the original IO table when adding it to the MRIO. The heterogenous classification is unique to Eora.

How is the USSR breakup handled?

The USSR formally dissolved on December 26, 1991. Eora contains a "Former USSR" country as well as all the USSR constituent countries (Russia, Ukraine, etc). The Former USSR values should be >0 through the end of 1991 then 0 in 1992 and onwards. The Russia, Ukraine, etc, values should be 0 in 1991 and earlier, and >0 in 1992 and onwards. This is how it should be, but due to many data conflicts in the statistics around this period, this clear delineation does not always hold. The dissolution of the USSR is not handled consistently in the data sources used as input to Eora.

Do Eora's results agree with those from other MRIOs (e.g WIOD, EXIOBASE, GTAP)?

Please refer to our paper on this question, "Convergence Between the Eora, WIOD, EXIOBASE, and OpenEU's Consumption-Based Carbon Accounts", and accompanying charts at worldmrio.com/confidence

How are the reliability statistics calculated?

The method for calculating standard deviations for the Eora MRIO tables is described in the journal article

Lenzen, M., Wood, R., Wiedmann, T. (2010) Uncertainty Analysis for Multi-Region Input-Output Models - A Case Study of the UK's Carbon Footprint. Economic Systems Research 22(1), pp43-63. 10.1080/09535311003661226

The method was first developed and piloted in a research project for the UK government.

The standard deviations of raw data used for constructing the MRIO tables can only be guessed, since very little information is available on the uncertainty of macroeconomic and input-output data. Hence, the standard deviations of raw data, and as a consequence also the standard deviations of the MRIO table elements, are based on assumptions, or you may say user settings. The Eora tables as published were estimated assuming that national input-output tables were most reliably, with the narrowest standard deviation settings, followed by UN Main Aggregates and Official Country data (for years where national input-output data do not exist), and then followed by UN Comtrade data. The latter were considered least reliable, partly because of severe conflict and errors that have previously been identified also by other research teams.

A set of Eora tables should be viewed as based on a particular world view of uncertainty, or reliability. For other world views, one could re-specify standard deviations, and re-run the Eora construction routines. One would then obtain a different set of tables. Hence, there is no one unique set of MRIO tables.

Like the construction of any input-output table, the construction of the Eora MRIO tables is an underdetermined problem. This means that there are many more table elements to be estimated than there are raw data support points. In particular, for many small transactions, there are few or even no data available. These transactions are hence not much "constrained" during the construction of the tables, and can therefore easily adjust in order to accommodate more stringent requirements, such as balancing rules, or the value of certain important transactions. For more information on data uncertainty and adjustment, see the document "Reliability of the Eora tables" available for download from Eora's homepage.

Why do I find non-zero transactions that should really be zero, for example many non-zero off-diagonal elements in supply tables?

Like the construction of any input-output table, the construction of the Eora MRIO tables is an underdetermined problem. This means that there are many more table elements to be estimated than there are raw data support points. In particular, for many small transactions, there are few or even no data available. These transactions are hence not much "constrained" during the construction of the tables, and can therefore easily adjust in order to accommodate more stringent requirements, such as balancing rules, or the value of certain important transactions. This may lead to situations where a certain element that is given as zero by a data source, is adjusted to some small nonzero value during table construction. In practice, this is often the result of data conflict. Whilst our data source may say that the certain element is zero, another data source may prescribe a row or column (sub-)total that cannot be met unless this element is nonzero. The optimiser that is used for construction the Eora tables strikes a compromise between all data conflicts. This may lead to small values appearing in the tables where the user would expect zero values. These small values must be interpreted in the context of their often large uncertainties. In other words, if an MRIO transaction is given as US$ 10,000 with a standard deviation of US$ 50,000, then statistically this number is indistinguishable from zero, and must be interpreted as noise. However, if you do find a theoretically zero-value transaction with an exceptionally large nonzero value, please let us know. For more information on frequently appearing small elements and their importance for overall accuracy, see the document "Reliability of the Eora tables" available for download from Eora's homepage.

What does "conflicting data" mean?

IO tables should be balanced, however it is not always possible to produce balanced tables because of conflict in the underlying raw data.

Consider two examples. First, often reported exports from A to B do not match B's reported imports from A. At the global level this imbalance is large, up to 30%. In Eora we try to prepare a globally consistent, balanced MRIO, that best respects all available data while also trying to be balanced. It is impossible to respect all data while perfectly satisfy these conflicting criteria, so our published MRIO is not perfectly balanced. For most sectors in most economies we get very close to 1.00 balancing ratio, but for individual sectors, especially where data conflict is more or uncertainty worse, we achieve just .9 or .8 balancing. We provide detailed reports on the website about table balances. Table balancing is one of our primary measures of MRIO quality so we are constantly trying to improve, and perfect, balancing ratios.

Another example is conflicting GDP data. A national statistics office may publish one value for the country's GDP but the UN or World Bank reports a different value. Which to believe? We assign a reliability score to each conflicting values and use an optimization package to find a best-compromise value. This process is described in more detail in the papers.

Does UN data on taxes on products include imported products?

Taxes on products include both domestically produced and imported products. Documentation in the United Nations' System of National Accounts (SNA) states that "A tax on a product usually becomes payable when it is produced, sold or imported, but it may also become payable in other circumstances, such as when a good is exported, leased, transferred, delivered, or used for own consumption or own capital formation. An enterprise may or may not itemize the amount of a tax on a product separately on the invoice or bill which they charge their customers."

I am having trouble reading the files in Excel

Most of the files at the website are provided in zip'd bundles of comma-delimited .CSV, or tab-separated .txt files, that can be read using Excel. However note that many files are quite large and may be unweildy, or even not loadable, in Excel (depending on Excel version and available RAM). In general, we recommend using Eora in a programming environment like MATLAB, Octav, R, Stata, or Python. Some files are provided in .spbin format, suitable only for custom programming languages, and a few files are provided in .mat format, which is readable in MATLAB, Octave, and Python (and perhaps other languages).

Why don't the Eora results precisely match macroeconomic totals provide by UN, IMF, or another data source I use?

First, note that data on countrywise total exports and imports fundamentally conflict with global trade balances. One cannot achieve a balanced global multi-region input- output table whilst at the same time respecting data on exports and imports. This means that in a real MRIO table, either balancing conditions must be violated or raw data misrepresented. The current Eora tables that have been constructed with emphasis on a) representing large data items and b) fulfilling balancing conditions for large countries. For most countries, exports and imports are smaller than GDP, and in fact those exports and imports deviate somewhat from raw data given in the UN?s Main Aggregate database. For some countries such as Singapore and Hong Kong, exports and imports are larger than GDP, and for these countries, predominantly the GDP estimates deviate from raw data.

Why do imports given in Eora's national account balances disagree with imports given in the United Nations' Main Aggregates database?

There are two reasons for this discrepancy. The first one is simple. The Eora balance requires only imports into intermediate demand to be included, whilst the UN Main Aggregates database lists imports into intermediate and final demand. The second reason is a bit more intricate; it has to do with valuation of imports at different borders. A national account balance requires imports to be valued in purchasers? prices, that is including basic price, insurance and freight margins, and duties. However, imports in the UN Main Aggregates database are valued free-on- board (f.o.b.), that is excluding margins and duties, unless specified otherwise. Methodological issues like this are explained in detail in the 1993 System of National Accounts (SNA)

and the new 2008 SNA

The former, in its paragraph 3.85, says: "Imports and exports of goods are recorded in the System at border values. Total imports and exports of goods are valued free-onboard (f.o.b., that is, at the exporter's customs frontier). As it may not be possible to obtain f.o.b. values for detailed product breakdowns, the tables containing details on foreign trade show imports of goods valued at the importer's customs frontier (c.i.f. value), supplemented with global adjustments to f.o.b. C.i.f. values include the insurance and freight charges incurred between the exporter's frontier and that of the importer. The value on the commercial invoice may of course differ from both of these."

The latter, in turn, says in its paragraph 26.19: "Valuation principles are the same in the SNA and the international accounts. In both cases, market values are used, with nominal values used for some positions in instruments where market prices are not observable. In the international accounts, the valuation of exports and imports of goods is a special case where a uniform valuation point is used, namely the value at the customs frontier of the exporting economy, that is, the FOB-type valuation (free on board). This treatment brings about consistent valuation between exporter and importer and provides for a consistent basis for measurement in circumstances where the parties may have a wide range of different contractual arrangements, from 'exworks' at one extreme (where the importer is responsible for arranging all transport and insurance) to 'delivered duty paid' at the other (where the exporter is responsible for arranging all transport, insurance and any import duties). (...)"

Can the AISHA software be used to create a customized or region-specific MRIO?

Yes. AISHA is an MRIO-building engine. It draws in data, in a variety of formats, applies concordances, reconciles conflicting data, and produces a balanced, total MRIO. Eora is a global MRIO built using this software. It is possible to add countries, introduce new data, or adjust how binding are the data constraints in order to create a region-sepcific MRIO that puts a higher priority on some countries, and lower priority on others. For Eora we sought a reasonable balance between the various major data sources and focussed on achieving good results for the largest economies. It is possible to create Eora variants that better respect some countries' IO data and de-prioritize others'. For example a Latin America specific MRIO would achieve better results for Latin American countries and would do so by loosening the constraints on e.g. European, African or Asian countries' data.

How does Eora account for international transport?

International transportation services are counted as part of the difference between F.O.B (free on-board) and C.I.F (cost, insurance, and freight) prices. If a good is exported for a F.O.B. price of $1 and imported for a C.I.F. price of $1.10, the value of the transportation and trade services is $1.10-1.00 = $0.10; Ideally, IO tables follow GDP boundaries, so, for example if a Japanese company exports a good to the US using a Panamanian vessel the emissions are attribute to Panama. However, GDP data do not fit this ideal situation, thus we attribute the emission to the exporting and importing countries. The value of the transportation services, and associated emisisons, are attributed to the off-diagonal trade block between the Origin and Destination country.

Domestic transportation services are recorded in the appropriate domestic sector, and emissions from households, including private car fuel use, are included in the final demand columns of the satellite account.

How are exchange rates handled?

The MRIO is provided in current-year '000 USD. Input data in others currencies are converted to $US using the yearly average historical exchange rates provided by the IMF. Currently we do not provide a version of Eora in constant prices, though this has been done using GDP deflators; see for example Owen et at. 2013 and Lan et al. 2012