IRS FATCA Report Notifications Frequently Asked Questions (FAQs)

The IRS could not download the transmission with the IDES file ID, transmission ID and timestamp. Even though you successfully uploaded the transmission, it could not be downloaded before the seven day IDES retention period expired.

The IRS automatically downloads transmissions from IDES after receiving an alert from IDES that a transmission is available for download. A system failure or outage on either side of the IRS-IDES connection led to the failure to download.

You will need to upload the transmission referenced by the listed IDES Sender’s File ID and IDES Transmission ID in the error notification again. Please ensure that the IRS encryption key you used for the initial transmission has not changed. If it has, please re-encrypt the plain text version of the file you are sending with the new IRS key, and upload this new encrypted transmission to IDES. The IRS will receive notification when the transmission is available and will download it at that time. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

IDES automatically deletes transmissions that are not downloaded within seven days of upload. Additionally, once the download of a transmission is initiated by IRS, IDES will automatically delete the transmission in 24 hours. As a result of one of these automated deletions, your transmission is no longer available on IDES. You must upload the transmission to IDES again to satisfy FATCA requirements. Please refer to the IDES User GuidePDF, available on the IRS IDES Home, if you have any questions on how to prepare and upload transmissions to IDES. The IRS will be notified by IDES when your transmission is available, and will download it at that time.

The IRS was not able to process your file therefore the records within the file could not be processed. Once the IRS has successfully downloaded your transmission from IDES, the file will be processed and you will be notified of the results, including whether the file was successfully processed or if any additional errors were identified.

The IRS could not decrypt the file with the IDES file ID, transmission ID and timestamp after downloading it from IDES. There are three situations that may have occurred:
a) the AES key provided with the file was not the same as the AES key used to encrypt the payload
b) the AES key used to encrypt is of the wrong type/wrong size, or it is missing completely
c) the public IRS key used to encrypt the AES key was not valid
d) the payload and/or encrypted AES key file was changed or modified after encryption

For security reasons the IRS does not disclose which situation caused the decryption failure.

First, make sure you have the valid IRS public encryption key on your system, downloaded from IDES. Next, please encrypt the digitally-signed and compressed payload of the referenced file with a new AES key and then encrypt the new AES key with the valid IRS public key. Insert the re-encrypted payload and AES key files and a new XML header in an archive to create the IDES transmission. Finally, upload the transmission to IDES following all additional procedures (see IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Please follow the procedures in the IDES User GuidePDF, available on the IRS IDES Home, and your local encryption software to generate a unique, one-time use AES-256 key. You should be using this unique, one-time use AES-256 key to encrypt your payload and the valid IRS public key available on IDES to encrypt the AES key.

The valid IRS key is available on IDES. Please visit International Data Exchange Service for additional information and instructions on how to find and download the IRS public key for encrypting the AES key for transmission.

Please see the IDES User GuidePDF, available on the IRS IDES Home, for additional information and instructions on how to find and download the IRS public key for encrypting the AES key for transmission to the IRS. Also, please consult the documentation for your encryption software application for assistance in importing the IRS public key into your system after downloading.

The IRS could not decrypt the referenced file because the size of AES key file was incorrect. The IRS expects a 48 byte AES key file, consisting of a 32 byte (256 bit) key and 16 byte (128 bit) initialization vector combined in a 48 byte encrypted file. Please do not submit a request to correct, amend or void any of the records in this file until you receive a notification that this file has been received as valid. For more information on this notification, including the classification of a failed file decryption under an intergovernmental agreement (IGA), please see: IRS FATCA ICMM Report Notifications Page. For more information on formatting the AES key file, please consult the IDES User GuidePDF.

Added: 01-17-17

This notification indicates an issue specifically with the AES key file size. You may not be using the CBC cipher, required as of July 11, 2016 or the AES key file size may be incorrect for another reason.

Added: 01-17-17

Please follow the procedures in the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software to generate a unique, one-time use AES-256 key with CBC ciphering. You should be using this unique, one-time use AES-256 key to encrypt your payload and the valid IRS public key available on IDES to encrypt the AES key. Ensure that your 16-byte initialization vector is included with your AES key in the encrypted key file.

Added: 01-17-17

Please refer to the IDES User Guide, available on the IRS IDES Homepage, and your local encryption software for specific instructions on using the AES-256-CBC encryption process.

Added: 01-17-17

The IRS could not decompress the file with the IDES file ID, transmission ID and timestamp after download from IDES. This failure occurred either because the file was compressed using an unsupported compression tool/algorithm, one or more files in the transmission are missing compression (not zipped), or because the file became corrupted after compression but before the AES encryption step.

Please recompress the digitally signed XML file using a supported compression tool, and create a new IDES transmission with this file, following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for IDES transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

For a list of supported tools, please refer to the IDES User GuidePDF, available on the IRS IDES Home.

The IRS could not validate the digital signature on the payload file with the IDES file ID, transmission ID and timestamp, with your organization’s valid public key on IDES.

Please re-sign the file using the procedures provided in the IDES User GuidePDF, available on the IRS IDES Home, and your local encryption software package and recreate and upload the transmission to IDES following all procedures (see the IDES User Guide, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Please follow the procedures for your local encryption software and for IDES. See the IDES User GuidePDF, available on the IRS IDES Home, and your local encryption software for instructions on how to apply the digital signature.

The IRS detected one or more security threats embedded in the decrypted version of the payload and/or Sender Metadata files. The IRS cannot accept files with embedded security threats

For security reasons the IRS does not disclose specific threats identified on electronic communications received from third parties, or what is used to identify these threats. However, these threats can include items such as:

• hyperlinks embedded within received files
• JavaScript components
• executable files (e.g., .exe files)
• compressed archive files
• prohibited characters (Apostrophe (‘), Double Quote (")

These items should not be part of any submitted file.

Note that the Apostrophe (‘) and Double Quote (") characters are prohibited by IRS as they could pose a security threat. (For a full list of character restrictions, see FATCA XML Schema Best Practices for Form 8966). As these characters would not be detected by an antivirus product, you will need to take other measure to ensure these characters are not present in any of your files.

Please remove all prohibited characters from the payload and Sender Metadata files, then rebuild the full transmission for this payload file by following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) and scanning for viruses and other security threats with up-to-date antivirus software at each step in the process (digital signature, compression, encryption of the payload and AES key files, creation of the IDES metadata file, creation of the full transmission files) and upload the full transmission to IDES. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Generally, any up-to-date and widely accepted antivirus software product should be capable of finding any other threat that the IRS detected. The IRS uses such products for virus and threat detection and removal. However, the IRS does not recommend the use of any particular product for this purpose. Prohibited characters will not be detected by an antivirus product; you will need to take other measures (e.g., a text editor) to ensure these characters are not present in any of your files.

It is the sender’s responsibility to ensure all files are virus and threat free and comply with all IRS requirements and restrictions. Please contact your local IT support staff for assistance with this step, or consult the IDES User Guide and documentation provided by your antivirus software provider.

The IRS detected one or more computer viruses embedded in the decrypted version of the file. The IRS cannot accept a file with viruses present.

For security reasons the IRS does not disclose specific viruses identified on electronic communications received from third parties, or what is used to identify viruses. However, the viruses the IRS detects are typically found by up-to-date commercial anti-virus products.

Please rebuild the full transmission for this payload file by following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) and scanning for viruses and other security threats with up-to-date antivirus software at each step in the process (digital signature, compression, encryption of the payload and AES key files, creation of the IDES metadata file, creation of the full transmission files), then upload the full transmission to IDES. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Generally, any up-to-date and widely accepted antivirus software product should be capable of finding the virus that the IRS detected. The IRS uses such products for virus and threat detection and removal. However, the IRS does not recommend the use of a particular product for this purpose.

It is the sender’s responsibility to provide clean files, and to ensure all files are virus and threat free. Please contact your local IT support staff for assistance with this step, or consult the documentation provided by your antivirus software provider.

The referenced file has one or more XML schema validation errors.

Use of the ampersand (&) and less than (<) symbols are prohibited as they are not allowed by XML syntax rules and will cause the transmission to be rejected with a failed schema error notification. These symbols must be replaced with entity references.

Substituting any ampersand symbols with "&amp;" and less than symbols with "&lt;" in XML files will prevent the generation of the error notification.

The IRS is currently mandating that users do not use default namespaces, but use namespace prefixes for all elements. This guidance is temporary and the restriction will be lifted in the coming weeks.

Please verify the presence of prefixes for all elements in the referenced file, then revalidate the referenced file against the current version of the FATCA XML Schema (IRS Publication 5124 available at FATCA XML Schema) to identify and resolve the specific validation issue. Use this inspected file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

The MessageRefId schema field in the referenced file consists of one or more blank characters or exceeds 200 characters in length. This field should be a unique identifier for a report file and is required to be at least one, but not more than 200, alphanumeric characters and cannot be all blank characters.

Updated: 03-03-16

The FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the MessageRefId should be a unique identifying number (created by the sender) that identifies the particular message being sent. Although a MessageRefId consisting of all blanks is valid against the schema, the IRS does not consider a blank MessageRefId to be unique. Furthermore, the IRS has limited the MessageRefId and DocRefId fields to 200 characters. The IRS requires non-blank MessageRefIds and DocRefIds that are no more than 200 characters in length in order to be able to accept your file.

Updated: 04-11-17

Please correct the file by including a unique, valid alphanumeric character string in the MessageRefId field (see the FATCA XML User Guide, IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and that is no more than 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

The MessageRefId schema field in the submitted file is duplicative of another file you have submitted. This field should be a unique identifying number for a report file and is required to be a string of at least one alphanumeric character.

Updated: 03-03-16

While your file is in the valid XML format, comparison of MessageRefIds takes place outside of XML validation. FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the MessageRefId should be a unique identifying alphanumeric value (created by the sender) that identifies the particular message being sent. The IRS cannot accept more than one file from the same sender with the same MessageRefId.

Updated: 04-11-17

Please correct the file by including a unique, valid alphanumeric character string in the MessageRefId field (see the FATCA XML User Guide, IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and does not exceed 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

One or more records with DocRefId schema fields in the submitted file consist of one or more blank characters or exceed 200 characters in length. This field should contain the unique identifier of the specific account or pooled report it references and is required to be at least one, but not more than 200, alphanumeric characters, and cannot be all-blank characters.

Updated: 03-24-18

The FATCA XML User Guide (IRS Publication 5124 available at FATCA XML Schema) states that the DocRefId data element should contain the unique identifier of the specific account or pooled report it references. Although a DocRefId consisting of all blanks is valid against the schema, the IRS does not consider a blank DocRefId to be unique. Furthermore, the IRS has limited the MessageRefId and DocRefId fields to 200 characters. The IRS requires non-blank MessageRefIds and DocRefIds that are no more than 200 characters in length in order to be able to accept your file.

Updated: 04-11-17

Please correct the file by including a valid alphanumeric character string in all DocRefId fields per the FATCA XML Schema User Guide (IRS Publication 5124 available at FATCA XML Schema) that does not consist of all blanks and that is no more than 200 characters in length. Use this file to recreate an IDES transmission and upload to IDES following all procedures (see the IDES User GuidePDF, available on the IRS IDES Home) for transmission preparation and upload. The IRS will send another notification to you through IDES once your file has been downloaded and processed further.

Updated: 04-11-17

The IRS has received and successfully completed the first phase of processing your file. At this time, there is no action for you to take with respect to this notification. Individual records in this file will be processed further at a later date, and you will be notified if any errors are encountered and if you need to take any further action.

Updated: 03-24-18

Your certificate posted to IDES was not valid. The IRS cannot download a file from IDES if the transmitter certificate is not valid.

Added: 03-24-18

Please post a valid certificate to IDES. Then re-encrypt the FATCA XML file with a new AES key. Re-package and resubmit the payload file to IDES using the new valid certificate.

Added: 03-24-18

The IRS could not download the referenced file that had been posted to IDES. The file could not be decoded because the encoding mechanism used did not match what was listed in the IDES metadata.

Added: 03-24-18

The file encoding schema supported by the IRS is Base64.

Added: 03-24-18

Ensure the file encoding is valid. Currently the IRS only supports Base 64 file encoding for transmission through IDES. Re-encrypt the payload and repost the file to IDES. The IRS will send another notification to you through IDES after we have downloaded and processed your file further.

Added: 03-24-18

The IRS could not download the referenced file that had been posted to IDES. Your specified file format type and actual file contents were inconsistent.

Added: 03-24-18

The IRS supports 5 file formats:

Added: 03-24-18

Ensure the specified file format type and actual file contents are consistent and repost the file to IDES. Ensure the specified file format is one of the approved types that can be sent to the IRS. Ensure the file type included in the IDES metadata is consistent with the file type of the enclosed notification.

Added: 03-24-18

The IDES alert of a successful upload is information about the transmission of your file. IDES alerts cannot provide information about the receipt and processing of your files by IRS ICMM. The IRS should issue an ICMM Notification for every FATCA Report that is successfully transmitted through IDES letting you know the status of your FATCA Report. You should always receive a Notification within 24 hours, and in most cases within a few minutes, of the IRS ICMM system receiving your file. However, the IRS has identified specific instances during testing where ICMM Notifications are not issued to filers when certain errors are present. In addition, the IRS has identified circumstances in which filers did not download their notifications before the 7 day retention period expired, and these notifications were deleted and are no longer available for download. The IRS is working to address and resolve these issues.

In the meantime, there are a few things you can do to maximize your ability to receive notifications sent to you, and to determine whether a notification has been sent to in response to your file. These are as follow:

• First, make sure that e-mail alerts from IDES are not blocked as SPAM by your own e-mail system. Your e-mail system may have deleted it or may have sent it to you SPAM inbox. If you have been sent an alert that a notification is present, but the alert email is blocked you may never be aware of the notification’s availability for download.
• Second, make sure your IDES User Profile is configured to allow IDES to send you e-mails, including alerts regarding notifications. There is a box that can be set to either send or not send you an e-mail notification. If you would like to receive and e-mail notification make sure it is set to send e-mail notification.
• Third, check your IDES inbox over the next 24 hours following the upload of your file to IDES to determine whether there is a Notification waiting for download. Even if you have not received an e-mail Alert, the Notification could still be in your folder ready for download. After seven days the notification will automatically be deleted from the system.

If you have checked your folder in IDES and there is no Notification present after 48 hours or longer since your file was uploaded successfully, an error types which is suppressing a notification from being sent may have been detected on your file. A few things to check that may help include the following:

• Making sure the digital certificate you are using for signature and encryption for FATCA data has not expired or been revoked by your Certificate Authority.
• Also, you should double check the Metadata XML file that is part of your data packet, to ensure all of the mandatory data elements are correct. In particular, please make sure that FATCAEntCommunicationTypeCd is set to “RPT”, and that the TaxYear is set to “2014.”
• Make sure all of the entries are correct. Did you indicate you were submitting a FATCA Report? Did you select the correct tax reporting year (it should be 2014)? Etc.

Once you’ve checked these items, you should resubmit your file.

It is possible that you submitted your FATCA Report production files to the FATCA Report test environment instead of to the FATCA Report production environment. Any production files that are submitted to the test environment will not be processed and will need to be re-submitted to the production environment. Please do not submit production files to the test environment. In addition, please do not submit test files to the production environment.

Form 8809-IPDF needs to be submitted. Please follow the instructions for that form.

Updated: 03-24-18

Form 8508-IPDF needs to be submitted. Please follow the instructions for that form.

Updated: 03-01-18

Since this data is considered to be test data, and the IRS discourages submission of test data in its production environments, no further action should be taken with respect to this record. Please do not attempt to void, correct, or amend this record with additional test data. However, if you determine that the record is a valid record please resubmit with the proper DocTypeIndic value through IDES to the ICMM production environment.

Added: 09-14-15

This record does not need to be voided or otherwise modified in the test environment. If the records are valid production submissions, please submit through IDES to the ICMM production environment.

Added: 09-14-15

The IRS has received and successfully completed processing of your file. At this time, one or more record-level errors have been identified in your file and require correction. You will need to correct all identified record-level errors and resubmit the file.

Added: 09-14-15

It is possible for a FATCA XML file to validate against the FATCA Intergovernmental Schema while not complying with FATCA reporting requirements. The FATCA XML V1.1 User Guide (IRS Publication 5124) details rules for FATCA data elements needed to validate against the FATCA schema, as well as mandatory data elements and values which extend beyond validation but are needed to satisfy reporting requirements.

Added: 09-14-15

The record indicated by the DocRefId value included with the error descriptions in the notifications is the record that must be corrected and resubmitted.

Updated: 03-03-16

Only the record with the corrected data needs to be resubmitted. However, since the record must be transmitted in a valid FATCA Report file, the full file must have sufficient data from the original file to pass XML validation and other checks, as defined in IRS Publication 5124PDF (pdf 1.59MB), including MessageSpec and Reporting FI data elements. In addition, the following changes from the original file are necessary:

• The DocTypeIndCd value should be “FATCA2” for corrected data
• The MessageRefId and DocRefId values for the file being corrected must be provided in the CorrMessageRefId and CorrDocRefId fields for the submitted file.

Updated: 03-03-16

The “TIN not in IRS specified format” error is generated when a non-GIIN value for a TIN data element is not in a valid format for a U.S. TIN. A value for a TIN data element must be either in a GIIN format or in one of the following formats for a U.S. TIN to be considered valid when filed:

• Nine consecutive numerical digits without hyphens or other separators (e.g., “123456789”)
• Nine numerical digits with two hyphens, one hyphen entered after the third numeric digit and a second hyphen entered after the fifth numeric digit (e.g., “123-45-6789”)
• Nine numerical digits with a hyphen entered after the second digit (e.g., “12-3456789”)

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains only one character repeated" error is generated when a US TIN is in one of the valid formats specified in Q7 above, but consists of nine digits that are all the same (ex. 555555555, 111-11-1111, 33-333333) or when a non-US TIN, which does not have to conform to the formats specified in Q7, consists of digits or characters that are all the same (ex. 9999999, XXXXXXX). A valid TIN will not consist only of one repeated character, regardless of country of origin.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains non-numeric characters" error is generated when a US TIN is in one of the valid formats specified in Q7 above, but includes any characters other than numeric digits (1-9) or "-" in the positions specified in Q7. A valid US TIN will not include any non-numeric characters.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

Though the nine digits in the US TIN you have provided are the correct TIN for the person or entity being documented, you may have used an incorrect format for the TIN. Please see Question 7 above for the correct formats to be used for US TINs in FATCA reporting.

Updated: 03-24-18

The 21 record-level error codes, descriptions, and remedial actions are provided in Section 5.4 of Publication 5189, The ICMM Notifications User GuidePDF. 

Updated: 03-24-18

Each record will be associated with a report-level DocRefID (Account, Pooled or Nil Report DocRefID) as well as one or more organization-level DocRefIDs (ReportingFI DocRefID, Intermediary DocRefID, and/or Sponsor DocRefID). If any of these DocRefIDs do not follow the DocRefID formatting requirements (see FATCA XML Schemas Best Practices for Form 8966 DocRefId), you will receive an “Invalid DocRefID” error. All DocRefIDs in the record should be checked to ensure they follow the formatting requirements. Please note that DocRefIDs must not include any non-alphanumeric characters, excluding periods and dashes. Prohibited non-alphanumeric characters include but are not limited to_, @, +, &, ! and *.

Updated: 04-18-18

The record-level error codes 8001 (Pooled Report Error), and 8007 (Account Report Error), and 8013 (Nil Report Error) indicate errors found with specific data elements in the record that must be corrected through a resubmission. In these cases the notifications will contain a “FieldErrorGrp” for each field-level error, with a description of the error (“FieldErrorTxt”) and the XML path for the data element (“FieldNm”) in error. Field-level errors are provided alphabetically by descriptionin the order in which they appear in the FATCA Schema in Figure 4-2 ICMM Field-level Errors for Electronic FATCA XML Reports PDF(pdf 147KB). Each field-level error must be corrected to resolve the record-level error.

Updated: 03-24-18

The procedures to correct, amend, or void specific records are below:
When a filer resubmits corrected record data in response to a “valid file with errors” notification from the IRS for an electronically submitted file, the following changes must be made within the “DocSpec” element for the corrected record:

• The “DocTypeIndic” element must be “FATCA2” to denote a corrected record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being corrected was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being corrected
• All fields identified in the error listing for the record in the notification must be corrected.
  In addition, all other record elements from the original record submission must be included, and the resubmitted file with the corrected record data must represent a valid FATCA XML file.

Amended records in which a filer chooses to amend (change or edit) previously submitted records are prepared similarly to corrected records. To submit an amended record, the filer must make the following changes within the resubmitted record:

• The “DocTypeIndic” element must be “FATCA4” to denote an amended record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being amended was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being amended
• All fields in the amended record must have values that the filer wishes to report to the IRS for the relevant account or pooled report.

Voided records in which a filer wishes to delete a previously submitted record are submitted in the following manner:

• The “DocTypeIndic” element must be “FATCA3” to denote a voided record
• The “CorrMessageRefId” element must be set equal to the “MessageRefId” for the original file in which the record being voided was contained
• The “CorrDocRefId” element must be set equal to the “DocRefId” for the original record being voided
• All fields in the voided record must have the same values as the original record being voided (deleted).

Updated: 03-03-16

The IRS agrees that this scenario is not an error by the filer. The ICMM system will misinterpret a MonAmnt_Type element with additional trailing zeroes after the second position to the right of the decimal point in the element; as a result the filer will receive a Valid File Notification (with Record-Level Errors) or NVF Notification because of the additional trailing zeroes. The MonAmnt_Type data with additional trailing zeroes are valid according to the FATCA XML Schema v2.0.

As of March, 24, 2018 this error condition is no longer being reported in NVF Notifications. For notifications received prior to that date, filers that receive an error for that reason (schema-valid MonAmnt_Type value with additional trailing zeroes) may ignore that error in the NVF Notification; those conditions do not require correction. However, please correct all other documented field-level errors on any other elements in the NVF notification.

Updated: 03-24-18

The IRS has received your Form 8966 and has identified errors in your document that require correction. You will need to correct all identified record-level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Updated: 03-24-18

The record error code on the paper notification is one of 4 record-level error codes provided in Table 4-3 which also contains descriptions and remedial actions for each error type.

Added: 09-14-15

These values provide the Part and Line reference, and standard description for each error found on your submitted Form 8966. Field-level errors are provided alphabetically by description in Figure 4-4 ICMM Field-level Errors for Paper ReportsPDF (pdf 101KB). Each field-level error must be corrected to resolve the overall record-level error.

Added: 09-14-15

Corrected Forms 8966 must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

The IRS has received your Form 8966 submitted as a pool report and we have identified errors and inconsistencies in your document that require correction. You will need to correct all identified record level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions

Added: 01-17-17

Corrected Forms 8966 for pool reporting must have complete entries for all required fields. Please resubmit all data, including corrected data, from your original Form 8966 on your corrected form.

Added: 01-17-17

The IRS has received your Form 8966 and has identified errors in your document that require correction. You will need to correct all identified record-level errors and resubmit the Form. Please mark the new form as “Corrected” by checking the box at the top of the first page, and send to the address indicated in the instructions.

Added: 01-17-17

All submitted Forms 8966, whether original, corrected, amended, or void forms, must have complete entries for all required fields. All appropriate fields should be populated with either data from the originally filed form or changes to reflect the corrections to the errors or amendments.

Added: 01-17-17

To resubmit a Form 8966, paper filers should submit a new Form 8966 with all appropriate fields populated with either data from the originally filed form or changes to reflect corrections or amendments:

• To correct an account or pooled report, in response to error notifications received from the IRS, make corrections to the fields in the part and line numbers, specified in the error notification, and check the “Corrected Form” box
• To amend or change an account or pooled report, submitted on a previously filed Form 8966, change the fields that need edits and check the “Amended Form” box
• To void or delete a previously filed Form 8966, check the “Voided form” box.

In all cases, fields from the original submission, that are not being corrected or edited, must be populated with the same data as the original filing (note: voided forms must include the same data as the original form being voided).

The table in, Figure 4 3 ICMM Record-level Processing Error Codes (paper filing)PDF (pdf 10KB), provides the codes, descriptions, and remedial actions needed for record - level errors ICMM will detect in records on paper Forms 8966. Four digit record-level error codes are always provided when record-level errors are present. Unlike the electronic case, in which a single file can contain multiple account reports and pooled reports as records, a single Form 8966 is considered to be a single, standalone record. A filer can only document a single account or pooled report on each paper Form 8966, and cannot file both types of reports on a single form. Also, unlike the electronic case, there is no way to identify a specific Form 8966 submitted by a filer; that is, there is no analog on the paper filing side to the MessageRefId and DocRefId data elements in the FATCA XML schema which can be used to exactly identify prior paper records. The IRS will need to analyze the filing history from a given filer to determine if corrections to errors on specific paper account and pooled reports have been provided. Because there is no way to directly correlate corrections to original submissions with errors, the record-level errors in electronic filing centered on corrected or amended reports with no matching originals have no paper counterparts, so the range of paper record-level errors is smaller.

Updated: 03-03-16

The “TIN not in IRS specified format” error is generated when a non-GIIN value for a TIN data element is not in a valid format for a U.S. TIN. A value for a TIN data element must be either in a GIIN format or in one of the following formats for a U.S. TIN to be considered valid when filed:

• Nine consecutive numerical digits without hyphens or other separators (e.g., “123456789”)
• Nine numerical digits with two hyphens, one hyphen entered after the third numeric digit and a second hyphen entered after the fifth numeric digit (e.g., “123-45-6789”)
• Nine numerical digits with a hyphen entered after the second digit (e.g., “12-3456789”)

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains only one character repeated" error is generated when a US TIN is in one of the valid formats specified in Q7 above, but consists of nine digits that are all the same (ex. 555555555, 111-11-1111, 33-333333) or when a non-US TIN, which does not have to conform to the formats specified in Q7, consists of digits or characters that are all the same (ex. 9999999, XXXXXXX). A valid TIN will not consist only of one repeated character, regardless of country of origin.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

The “TIN not in IRS specified format, contains non-numeric characters" error is generated when a US TIN is in one of the valid formats specified in Q1 above, but includes any characters other than numeric digits (1-9) or "-" in the positions specified in Q1. A valid US TIN will not include any non-numeric characters.

If a filer has confirmed that the Account Holder is not required to have a US TIN in the agreed upon format then the filer does not need to re-file to correct this specific error. Any other errors included in the notification must be corrected and the filer should re-submit a corrected file for those errors only. The Account Holder TIN must be provided and cannot be blank characters in the TIN data sub-element.

Updated: 03-24-18

Though the nine digits in the US TIN you have provided are the correct TIN for the person or entity being documented, you may have used an incorrect format for the TIN. Please see Question 1 above for the correct formats to be used for US TINs in FATCA reporting.

Updated: 03-24-18