Japan-specific GIR data points at a glance
| Area | Japan position |
|---|---|
| Header localisation | TransmittingCountry = JP, ReceivingCountry = JP, MessageType = GIR, and Japan tells filers not to record SendingEntityIN, Warning or Contact. |
| MessageRefId | Japan format: JP + fiscal-year-start year + 13-character corporate number (or substitute identifier) + 3-digit unique suffix. |
| MessageTypeIndic | GIR101 = new filing; GIR102 = correction or deletion; GIR103 is not used in Japan. |
| Role codes | GIR401 = UPE; GIR402 = designated domestic filer; GIR403 = representative filer; GIR404 = other constituent entity; GIR405 = other corporation. |
| RecJurCode | For local filing roles GIR403, GIR404 and GIR405, RecJurCode can only be JP. If RecJurCode itself is wrong, Japan expects deletion and refiling rather than a simple overwrite. |
| FilingInfo / GeneralSection | If FilingInfo.DocTypeIndic is OECD1, GeneralSection must be included. |
| DocRefId | Japan builds DocRefId from the 22-character MessageRefId plus a 4-digit suffix; CorrDocRefId is mandatory for OECD2/OECD3 corrections and deletions. |
| Encoding / file type | XML must be UTF-8 with .xml. CSV must be .csv or .txt in Shift-JIS. |
| Data controls | Whole-number amounts, percentage values recorded from 0.0000 to 1.0000, half-width characters only, and certain strings are forbidden. |
Japan’s Pillar Two process is more prescriptive than a straight reading of the OECD GIR materials might suggest. The National Tax Agency routes the main compliance workstreams through the e-Tax Multinational Enterprise Information Reporting Corner. This includes the GIR filing, related ultimate-parent and designated-filer notice work, representative-filer filings where more than one Japanese entity would otherwise report, and the return package for Japan’s international minimum top-up tax. In practice, taxpayers need one portal environment, but the GIR filing and the top-up tax return remain separate filings with separate data preparation rules. View our Japan Pillar Two Filing Checklist.
Japan is not using a Swiss-style encrypted upload model. It accepts either XML or CSV for the GIR filing and, for accounting and tax teams, explicitly recommends CSV. The practical consequence is that many groups will not submit a hand-built OECD XML file at all. Instead they will prepare a Japan-specific CSV package, import that package into the reporting corner, run the pre-check, and submit from there.
Japan’s record guide starts from the OECD GIR schema but fixes several fields and adds local operating rules. In the message header, TransmittingCountry must be “JP”, ReceivingCountry must be “JP”, and MessageType must be “GIR”. Japan also tells filers not to record SendingEntityIN, Warning or Contact. The message identifier itself is not free-form: MessageRefId must follow a Japan pattern of “JP” + the year in which the reporting fiscal year starts + a 13-character corporate number or other filer-specific identifier + a three-digit suffix used to keep each submission unique.
Japan uses MessageTypeIndic in a narrower way than some practitioners may expect. GIR101 is used for a new filing. GIR102 is used where the submission corrects or deletes previously sent data. The guide expressly says GIR103 is not used. ReportingPeriod is the fiscal year-end date. Timestamp is required in the XML route, but in the CSV route it is not entered by the filer. GLOBEBody should not be repeated, and separate fiscal years should be filed separately rather than bundled into one message.
Japan also hard-wires several FilingInfo and FilingCE conventions. FilingCE.ResCountryCode must be “JP”. FilingCE.TIN is the Japanese corporate number, and when the filer’s role is GIR401, that TIN must match the ultimate parent TIN later in the file. The role codes apply as: GIR401 for the ultimate parent, GIR402 for a designated domestic filer, GIR403 for the representative filer under the Japanese representative-filer rule, GIR404 for another constituent entity, and GIR405 for another corporation outside those categories. For local filing roles GIR403, GIR404 and GIR405, Japan says RecJurCode can only be “JP”.
The FilingInfo document status rules are also tightly prescribed. FilingInfo.DocTypeIndic uses the OECD codes OECD1 for new, OECD2 for correction, OECD3 for deletion and OECD0 for re-submission of unchanged FilingInfo. If FilingInfo is OECD1, GeneralSection must be provided. If FilingInfo is OECD2 or OECD3, CorrDocRefId becomes mandatory. DocRefId follows a Japan-specific construction: the 22-character MessageRefId plus a four-digit suffix. The same logic then carries through to GeneralSection, Summary, JurisdictionSection and UTPRAttribution. If the item being corrected is RecJurCode itself, Japan does not allow a simple overwrite; the prior filing has to be deleted and the corrected filing resubmitted as new data.
Japan’s guide includes several validation points that are easy to miss if a team only looks at the OECD schema. Allowed characters are restricted to basic Latin characters plus tab, line feed and carriage return, and the guide says filers should use half-width characters. It also forbids the strings “–”, “/*” and “$#”. Amount fields must be rounded to whole numbers, not stored with decimals. Percentage fields are recorded as decimals from 0.0000 to 1.0000, rounded at the fifth decimal place. XML files must use the .xml extension and UTF-8. CSV files must use .csv or .txt and Shift-JIS. For TIN fields, Japan spells out the attribute coding: GIR3001 and GIR3002 for taxpayer identifiers, GIR3003 for a designated reference number, and GIR3004 when “NOTIN” is used.
The CSV route is not one spreadsheet. Japan breaks the GIR-equivalent filing into six record types and stores each record type in a separate file. Each CSV row has six columns: item name, value, attribute 1, attribute 2, attribute 3 and hierarchy level. The six record types are MessageSpec, FilingInfo, GeneralSection, Summary, JurisdictionSection and UTPRAttribution. For many domestic filers, not all six are needed, but the structure still matters because the reporting corner expects the folder and file naming conventions exactly as described in the NTA guide.
The upload object is the folder, not the individual CSV files. Japan tells filers to create a folder called GLOBE_OECD and a subfolder called 02_GLOBEBody. The message-header file sits at the top level as 01_MessageSpec.csv. FilingInfo and the other record-type files sit under 02_GLOBEBody. The guide names the content files as 02_GeneralSection.csv, 03_Summary_(sequence).csv, 04_JurisdictionSection_(sequence).csv and 05_UTPRAttribution_(sequence).csv. Sequence numbers run from 1 to 9999 with no gaps, and even a single file uses sequence 1. In the CSV examples, the practical header entered by the filer contains only four rows: ReceivingCountry, MessageRefId, MessageTypeIndic and ReportingPeriod.
Japan provides Excel templates that pre-populate item names and hierarchy levels, but they are only templates. Teams still need to delete rows that are not required and add rows for repeated items such as multiple RecJurCode values or repeated TIN elements. The guide also makes clear that if FilingInfo is new data, the GeneralSection file must be included. And because Summary, JurisdictionSection and UTPRAttribution can repeat by jurisdiction or exchange-recipient country, a group can end up with multiple numbered CSV files even for one fiscal year.
The GIR filing has a 19 MB transmission limit. Japan warns that CSV data expands by about 1.5 times when the reporting corner reads it, so a GLOBE_OECD folder that looks smaller than 19 MB on disk can still fail after import. If the file must be split, the guide tells filers to duplicate the whole GLOBE_OECD folder, keep record types 1 and 2 in every split package, remove record types 3 to 6 so there is no overlap, add split wording to FilingInfo.AdditionalInfo, assign a unique MessageRefId to each split package, and update the related DocRefId values so they remain aligned with the new message ID. MessageTypeIndic stays the same across the split packages.
Japan’s onboarding is closer to standard e-Tax enablement than to Switzerland’s portal-admin model. Before a filer can submit through the reporting corner, it needs the normal e-Tax starting setup. The e-Tax site says users need an electronic certificate, the reporting-corner prior-setup installer, and the browser extension e-Tax AP. It also says a start notification for e-Tax use must be filed with the competent tax office, which can be done online. Japan updated the reporting-corner setup package on 5 January 2026 and instructs users who installed it earlier to run the setup again.
Once the environment is ready, the reporting corner lets the filer import the XML file or the GLOBE_OECD CSV folder, run the pre-check and then submit. The portal page says the pre-check function is available for GIR-equivalent filings and requires the user to log in first. That pre-check step is worth treating as mandatory in internal process terms, because Japan’s local rules are detailed enough that a file can be OECD-looking but still fail the Japanese validations on format, encoding, identifiers or file structure.
Japan also provides a post-filing retrieval route. The e-Tax FAQ says the sent file can later be checked from the reporting-corner message box by downloading the transmitted file in XTX form and opening it through e-Tax software (WEB version) for form-style display. The practical workflow is: open the message box, log in, open notices and received messages, select the relevant filing, save the XML-format/XTX file, and then read it back through the WEB version of e-Tax. That is useful for evidence retention because the transmission package is otherwise easy to lose once the team moves on to the next filing cycle.
Japan’s top-up tax return is filed separately from the GIR. The reporting corner says the return for the international minimum top-up amount is required unless the relevant fiscal year has no taxable standard international minimum top-up amount. Where it is required, the filing starts from the “create the international minimum top-up tax return” function. The return package includes Bepyo 20, the CSV-based appendices to Bepyo 20 and the supporting attachments. The NTA recommends using its dedicated CSV preparation tool for the appendices, and those appendices are filed as CSV rather than as PDF.
If you haven’t got a subscription you can join up below.
| Cookie | Duration | Description |
|---|---|---|
| cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
| cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
| cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
| cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
| cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
| viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |