Already logged in
Home Account Logout
Already logged in
Home Account Logout
Already logged in
Home Account Logout
Please use your employer or university domain email address for registration. We generally do not accept registrations from gmail.com and 126.com email addresses

Please use your company or university domain email address for registration.

No password needed. You will receive a login link via email.

Privacy policy We do not share your email address. We will only contact you as needed about important updates. You can close your account at the Account page at any time. This site does not use any tracking cookies.

Frequently Asked Questions

General

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. 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, 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. 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, 10.1080/09535314.2013.769938

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

Working With Data Files

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. Some files are provided in different units. For example, the individual country tables are provided in USD, not '000 USD. When files are provided in units other than '000 USD the unit will be indicated with the file.

How to I open .txt files?

Many files are available as .csv or .txt files. These can be opened in Excel, Matlab, Python, R, etc. To open .txt files in Excel use "Open" on the File menu and use Tab-delimited file.

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 .mat format, which is readable in MATLAB/Octave and Python.

About the IO Tables

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.

What are re-exports/re-imports?

This is 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."

What does the “private households” sector mean?

It is defined here at pages 182-183

What is the “FISIM” sector?

FISIM is an acronym for “Financial Intermediary Services, Indirectly Measured”. Financial intermediary services refer to a range of financial services (e.g. lending, insurance, etc.). These can be quite large in some countries. It is often a difficult line item to estimate accurately. For more on FISIM it is recommended to read more about the SNA at the UN Statistics Division.

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.

For more, see also the Eora Confidence whitepaper.

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."

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

Is Eora available in constant prices?

The MRIO is provided in current-year '000 USD. For the time being we do not have a constant-price version. It is possible to use the USD GDP deflator to create a constant-price version. This is done for example in the "Material Footprint of Nations" paper by T. Wiedmann:

Wiedmann, T., H. Schandel, D. Moran, J. West, M. Lenzen, K. Kanemoto, S. Suh. The Material Footprint of Nations – Reassessing Resource Productivity. Proceedings of the National Academy of Sciences10.1073/pnas.1220362110

What does CO2b refer to in the satellite accounts?

CO2b refers to short-cycle CO2 from biomass burning. This is typically CO2 emissions from land use, land use change, and fires (sometimes called "LULUCF").

How is Nowcasting done in Eora?

Official reports of national macroeconomic statistics including GDP, gross imports, exports, and consumption, are available through 2018. Eora uses nowcasting, based on the IMF’s World Economic Outlook (WEO), to estimate MRIO tables for years 2019-2021. The nowcasted statistics for 2019 are expected to be relatively reliable, however as the Corona crisis is still unfolding, and its economic impacts are not well-measured, we encourage users to take the results for 2020 and 2021 as provisional.

Eora’s nowcasting is based on a simple and transparent approach. The MRIO table from 2018, the last observed year, is taken as the initial estimate of the 2019 table. Mathematical optimization is then applied to find a new MRIO table in which (1) national GDPs are scaled up/down to match their values as forecast in the IMF World Economic Outlook, (2) the entire MRIO table is balanced, i.e. gross output equals gross input and gross exports equal gross imports, and (3) the new table diverges as minimally as possible from the initial estimate while adhering to the two aforementioned constraints. The procedure is repeated in subsequent years, e.g. using 2019 as the initial estimate of the 2020 table, etc.

GHG emissions accounts are also nowcasted. Eora’s main GHG satellite account is based on the PRIMAP-HIST database. The most recent version of this database covers through the year 2018. GHG emissions for 2019-2021 are nowcasted using a two-step procedure. First, a linear regression model is applied to the last 10 years of GDP and gross national GHG emissions to estimate the average annual change in carbon intensity (emissions per unit GDP) in each country and predict the carbon intensity in the nowcasted years. Second, this new carbon intensity factor is applied to the nowcasted GDP.

These results offer a reasonable baseline dataset with a timely nowcasted MRIO table. Specific applications may also benefit from combining the nowcasted Eora data with other recently updated or forecasted data.

Where can I find documentation for the classification used for Primary Inputs and Value Added?

At the metadata page.

Resolving Data Issues

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 = vertcat(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 (also called "Statistical Discrepancies" sector is introduced to absorb these imbalances.

Another way to understand the Rest of World / Statistical Discrepancies sector is that it is trade with other countries not explicitly distinguished in the model.

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)

Or expressed another way:


Row total: Sum over sheets 1,4,5 (basic price, taxes on products, and subsidies on products)
Column total: sum over basic price only
Some values in the satellite account are the same for multiple years

When no more recent data is available, Eora provides the last reported year's data. For example, CDIAC ceased reporting in 2014, so the satellite account for all years %>2014 will display the 2014 values.

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

Duplicate sector labels exist in a few countries (Chile, Kazakhstan, Peru, Ukraine, and Uzbekistan) [Open Issue]

First, note that Supply-Use Tables (SUTs) often use the same sectoral classification for the Supply and Use tables (this is indicated by the Industry or Commodity Entity in the label metadata) and therefore the same sector labels will appear in both the Supply and Use tables. However, there a few known duplicate sectors in Commodity-Commodity IO tables in Eora as well. These labels are incorrect. They will be fixed in a future update.

In the meantime, the workaround is simple. The first occurrence of the sector is the primary industry and the second occurrence is the secondary industry. For example, the first occurrence of the Seafood industry in Chile refers to primary harvesting activity, and the second occurrence refers to industries involved in packing, processing, and transporting fish after it is returned to shore. Similarly, the Primary Metals Products sector in Ukraine and Kazakhstan refers to primary products and the second occurrence refers to processed or more complex products. The duplicate "Services to Companies" sector in Peru is the result of a translation error. At the next opportunity we will revisit the Peru IO table translation from Spanish to English and correct the sector label. The complete list of duplicate sectors is as follows:


Index Country       CountryA3 Entity  Sector
2431  Chile        CHL  Commodities Seafood
2438  Chile         CHL Commodities Seafood
6280  Kazakhstan  KAZ Commodities Metal Products
6324  Kazakhstan  KAZ Commodities Metal Products
9008  Peru          PER Industries  Services to Companies
9054  Peru         PER  Commodities Services to Companies
9056  Peru          PER   Commodities Services to Companies
12026 Ukraine         UKR Commodities Metal Products
12070 Ukraine         UKR Commodities Metal Products
14266 Uzbekistan  UZB Commodities Metal Products
14284 Uzbekistan  UZB Commodities Transportation
14310 Uzbekistan  UZB Commodities Metal Products
14360 Uzbekistan  UZB Commodities Transportation
Why do I find non-zero transactions that should probably be zero?

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 due to 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 (e.g. 100, 1e-3, or 1e-6) appearing in the tables where one might 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.

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 in the documentation area.

In the vast majority of cases these small nonzero elements do not have any substantitve effect on the analysis. You can test this by solving with Eora directly, then set all elements <1000 to 0 and re-solve, and compare the results.

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 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). (...)"

I see a case where results from a CBA (Scope 3)-based calculation don’t exactly match the corresponding PBA total. Why is this?

Due to factors such as numerical instability in the matrix inverse computation and slight differences in how erroneous/negative values are handled, there may arise minor discrepancies between CBA totals and PBA totals. Such discrepancies due to computation details are usually around <3-5%.

We observe data jumps from 2015 to 2016. Why is this?

Normally Eora is built iteratively, year by year. This approach minimizes any yearly variability. For the update published in Q12022, containing years 2016-2021, the new years 2016-2021 were run as one block and the old years 1990-2015 were left as-is. This seems to have resulted in a situation with a visible seam between the two runs at the 2015/2016 junction. The QA checks verifiy the holistic accuracy the timeseries, including over 2015/2016, but we recognize that variability in individual values can still be troublesome for users upgrading from 2015 results. The reasons for the jumping values are complex, but essentially are due to the fact that the raw data we receive from government agencies is also revised retroactively (e.g. a value for year 2015 published in 2018 could be revised when that value is republished in 2021) and due to minor changes and fixes in the Eora code pipeline. The best solution to this would be to re-run the entire model for all years and overwrite the prior results. This would address the issue of the visible seam, but users moving from the older data vintage would still see results change.

The largest driver of these jumps is primarily revised official statistics. The design philosophy of Eora is to combine and present the official values from statistical offices as accurately as possible. Eora aims to use minimal interpolation and data smoothing.

In terms of solutions, users can employ standard techniques to manage data version changes, such as using indices, applying smoothing such as rolling averages, or publishing results with vintage. Audiences are increasingyl aware of and sophisticated about data vintaging issues since these are widespread across many datasets, and are not unique to Eora.