Block 9 in SAP: how the file counts itself, and why one line out of place fails validation
Four records close the EFD ICMS/IPI file (part of SPED, Brazil's digital tax reporting system; ICMS is Brazil's state value-added tax): 9001, 9900, 9990 and 9999. They carry no tax and no document, only the count of everything that came before, and Practical Guide 3.2.4 uses this count to check the whole file.
The tax authorities write the rule. DFSpro answers for the system: setting up the solution that builds the file and proving that it counts the records the way the Guide requires.
Start with the question for your role
Whoever checks the file closing is usually tax, IT or audit, and each role looks for its own answer.
01Tax and fiscal
Which records close the file, what the Guide says to check and what happens with a file that has no activity.
See the role section02IT and SAP
Which count fields exist, in what order the records appear and how to recount outside the solution.
See the role section03Audit
What evidence shows that the count was checked and not assumed, and where it is kept.
See the role section04Controllership
Who checks the closing before transmission and who keeps the evidence for each period.
See the role section05Project management
Where Block 9 fits in the test plan and why it is the cheapest proof for the file.
See the role sectionBlock 9 totals the file, and the count only closes if each record is counted once
Block 9 is the closing of the EFD ICMS/IPI digital file. The 9900 carries one line for each type of record in the file, with the number of times it appears, the 9990 reports how many lines the block itself has and the 9999 reports how many lines the whole file has. In our reading, the result depends on the solution that builds the file counting what was actually written, and not only what was selected.
What the tax authorities publish
The structure of the four records and the three count checks (9900, 9990 and 9999), on pages 325 and 326 of Practical Guide 3.2.4, dated 30/07/2026.
What the tax authorities do not publish
How your solution builds the file, at which step it counts the lines and what it does when a count does not close: this is in the design of your environment.
What DFSpro proves
That the total of each record in the 9900 matches the generated file, that the 9990 and 9999 close, and that the recount is repeated with every new version, with evidence filed per period.
- To learn where the records counted here come from, start with SPED Fiscal in SAP.
Because it is only counting, Block 9 involves no tax thesis: there is no rate, tax base or credit to interpret. The risk is operational, so the proof is mechanical, repeatable and cheap to keep.
Four records that close the file, with the position of each in the hierarchy
Each Block 9 record has its own function, summed up in a card, and the Guide describes what it counts. The table shows the code, name, level, occurrence and page of each closing record.
Block opening
The 9001 opens the block, and the Guide says it must always be generated.
Records: 9001.
Total per record
The 9900 repeats one line for each record code in the file, including those that come after it, with the number of occurrences.
Records: 9900.
Block closing
The 9990 reports the total number of lines in Block 9, counting the block's opening and closing lines and also the 9999.
Records: 9990.
File closing
The 9999 closes the file and reports the total number of lines, counting the 9999 itself.
Records: 9999.
Checking the closing needs no interpretation: it needs consistent information, automatic validation and a solution that records the transmission of each period.
| Record | Name in the Guide | Level | Occurrence | Page |
|---|---|---|---|---|
| 9001 | Block 9 opening | 1 | one per file | 325 |
| 9900 | File records | 2 | several (per file) | 325 |
| 9990 | Block 9 closing | 1 | one per file | 325 |
| 9999 | Digital file closing | 0 | one per file | 326 |
The full fields and validations of each record are in the Practical Guide sheet, on the matching page.
Eight passages from the Guide that decide whether the file closing passes
The Guide asks eight main things of the file closing. The sheet of each record has more validations, and the technical team should rely on it.
When the block exists
“This record must always be generated and represents the opening of block 9.”
Record 9001, page 325.
What each line totals
“All the records referenced in this file, including those after this record, must have a line totaling their number of occurrences.”
Record 9900, page 325.
Checking the quantity
“checks whether the number of lines in the file of the type entered in the field REG_BLC of record 9900 equals the value entered in this field”
Record 9900, page 325.
What goes into the block sum
“the number of lines to be entered must also consider the opening and closing records of the block themselves”
Record 9990, page 326.
The 9999 enters the block count
“record 9999, although it does not belong to Block 9, must also be counted in this sum”
Record 9990, page 326.
File total
“the number of lines (records) in the whole file equals the value entered in the field QTD_LIN”
Record 9999, page 326.
All blocks, in sequence
“It is mandatory to submit all blocks, in sequence, according to the Blocks Table below”
Chapter II, section 1, page 7.
File with no activity
“even with activities suspended in the period, that is, with NO ACTIVITY, they must submit the file reporting, at a minimum, the mandatory records”
Chapter II, section 5, page 326.
Fields and validations, sheet by sheet
- 9900, field REG_BLC, completion. “enter each of the valid record codes of this file, which will be totaled in the next field QTD_REG_BLC” Page 325.
- 9999, field QTD_LIN, completion. “the number of lines to be entered must also consider the record itself 9999” Page 326.
General rules of the file that Block 9 closes
- From 0000 to 9999. “Between the initial record (record 0000) and the final record (9999), the digital file is made up of blocks, each with an opening record” Page 7. The 9999 is the final record of the file, and the count of the whole file ends there.
- Each block opens and closes. “each with an opening record, with data records and with a closing record” Page 7. That is why the 9001 and 9990 exist and are included in the sum of Block 9 itself. The proof checks that the solution generates both, and not only the middle.
- Block 9 ends the file. “at the end, block 9, which closes the file of the EFD-ICMS/IPI” Page 7. Block 9 closes the sequence of blocks. The 9999 comes after the 9990 and, even so, the Guide says to add it to the Block 9 count.
- Sequential and ascending order. “Within the hierarchy, the order of presentation of the records is sequential and ascending.” Page 7. If the solution reorders records after counting them, the 9900 list can stay right while the file order is wrong. The two tests are separate.
- Mandatory record. “All records marked “mandatory record” must appear in the file.” Page 7. In a file with no activity, these records are the minimum the 9900 needs to total. Check the list of mandatory records for your period.
- One occurrence per file. “must appear only once in the digital file” Page 7. The Block 9 records marked as one per file (9001, 9990 and 9999) cannot appear twice. A repeated 9999 breaks the occurrence rule.
- An omitted field is a structure error. “leaving out fields causes an error in the record structure” Page 7. It also applies to the 9900: the three fields (REG, REG_BLC and QTD_REG_BLC) must be in every line, even if one seems redundant.
- A record with no information is not included. “Records for which there is no information to be provided must not be included in the EFD-ICMS/IPI file.” Page 8. A record that the solution generates empty and then removes must also leave the 9900 count. This case is worth testing.
- Opening and closing in the PVA. “the records that open and close blocks will be generated automatically and will not be displayed” Page 7. When the file is keyed in the PVA, the 9001 and 9990 appear without anyone seeing them. In a file generated by a solution, the check is manual.
- Parent record before child. “Generating the file requires a “Parent Record” to exist when there is a “Child Record”.” Page 8. The 9900 count adds parents and children. If a child record is discarded after counting, the 9900 total no longer matches the file.
- Records that repeat. “Records that contain table items, totals, documents, among others, may occur one or more times in the file for a given type of situation” Page 7. The 9900 is of this type: it appears once for each record code in the file. The proof checks one line per type, not a single line.
- Layout of the period. “For the delivery of the EFD-ICMS/IPI the layout in force at the time of the calculation period must be used” Page 30. The Block 9 recount holds for the layout of that period. In a file for an old period, check which record list was in force.
The text in quotation marks is from the Guide, translated here, with the PDF page. The neighboring comments are DFSpro's guidance for whoever implements the file.
Six simple checks that show whether the file closing is correct
The Guide defines the three counts. DFSpro recommends tests to check that your solution respects them, and the scenarios change with the program that builds the file.
- Independent recount. Count the lines of each record type in the finished file, with a separate program, and compare with each line of the 9900. Every difference is a finding.
- Records after the 9900. The Guide says to also total the records that come after the 9900. Check that the records after it are in the list, with the right count.
- Block 9 sum. Add the lines from the 9001 to the 9990 and add the 9999. Compare with the 9990 field, which, according to the Guide, includes the 9999 in this sum.
- File total. Compare the 9999 field with the number of lines in the whole file, counting the 9999 itself.
- Month with no activity. Generate a period with no activity and check that all blocks appear in sequence, with only the mandatory records, and that Block 9 closes the same way.
- Replacement file and new version. Repeat the recount for every replacement file and for every new version of the Guide or the solution. The count is mechanical, so the proof is cheap and worth repeating.
- At which step does the solution count the records: before or after writing the file?
- Does the 9900 come from the final file or from a temporary list built during generation?
- What does the solution do when a line is removed after the count?
- Is there an independent program that recounts the lines, or is the check manual?
- Who keeps the checked file for each period, and for how long?
How Block 9 fits in the larger test plan is in tax tests. When the solution is replaced or updated, the suggested order is to recount Block 9 first, then check the document blocks and, last, the calculation, because a file whose count does not close does not deserve a detailed analysis.
Who checks the count, and when the count is redone
The count needs no tax decision, but it needs an owner, a routine and evidence: without these three, the check depends on the memory of whoever generated the file.
Check owner
Define who checks Block 9 before transmission: tax, IT or the team that runs the solution. The plan comes from DFSpro, and the choice of who carries it out is your company's.
Evidence kept
Keep, per period, the recount, the checked file and the validation result. In an audit, this folder shows that the count was proven, not assumed.
Trigger to redo
Redo the proof when the layout changes, when the solution that generates the file changes, when the set of blocks used changes or when the replacement file rule changes.
Your company's decision
The submission profile, the content of the file and the transmission rest with your company, according to what the tax authorities and your State Finance Department (Secretaria de Fazenda) require. Our part is technical: building, setting up and proving what the system generates. No tax interpretation enters the closing check, because the validation is arithmetic.
Who published each piece of information, and when
Receita Federal (Brazil's federal tax authority) and SPED
The Guide version in force on your transmission date and the validator (PVA) version your team uses. The behavior of your solution when generating the 9900 in a very large file. What SAP's current documentation says about generating the file.
Questions from those who check the file closing in SAP
01What is the function of the last block of the EFD file?+
Block 9 is for control: according to Practical Guide 3.2.4, it represents the record totals and is used in cross-checks and verifications. It comes after all the other blocks and closes the digital file.
02What does record 9900 total?+
One line for each record code present in the file, with the number of times it appears. The Guide says to include also the records that come after the 9900. The validation checks that the quantity entered equals the number of lines of that type in the file.
03How is the 9990 line total calculated?+
The Guide says to count the lines of Block 9, including the block's own opening and closing records, and to add the 9999, which does not belong to the block but enters this sum. The validation checks that the number of lines in the block equals the value entered.
04And the 9999 line total?+
It is the total number of lines in the whole file, counting the 9999 itself. The validation checks that the number of records in the whole file equals the value of the QTD_LIN field.
05Can Block 9 be missing when the establishment had no activity?+
No. The Guide says it is mandatory to submit all blocks, in sequence, and that a required establishment, even with no activity, submits at least the mandatory records. Whether your establishment is required is your company's decision.
06Does the solution that builds the file calculate Block 9 on its own?+
In general the count is automatic, but this varies with the solution and the version, and the Guide does not describe the behavior of each product. The safe way to know is to recount a file generated in your environment: if the three counts close, the solution meets the Guide.
07What to do when the 9900 does not match the file?+
The Guide defines the validation, not the fix. Our recommendation is to find what caused the difference (a record written but not counted, or counted but not written) and regenerate the file, instead of editing the total by hand. Editing the number hides the defect and it comes back the next month.
08What investment does the Block 9 proof need?+
There is no official figure or public price. Because the count is mechanical, the cost depends on the number of establishments, the volume of files and the way the solution builds the closing. A proposal comes after a diagnostic of these two fronts.
09Do I need to redo the proof with every version of the Guide?+
The reference Guide for this page is version 3.2.4, updated on 30/07/2026. Because the recount is cheap, we recommend redoing it with every new version of the Guide, the layout or the solution that generates the file.
10Why is Block 9 the cheapest proof for the file?+
Because the count is mechanical: there is no interpretation of a rule, rate or credit, only a comparison of numbers. A simple program that recounted the lines would already validate the three checks, and the result is objective: it closes or it does not. This makes Block 9 a good first test of any change in how the file is generated, before the more complex steps.
11What changes in Block 9 when the file is a replacement?+
The Guide defines the same validations for any file. Because the number of lines changes along with the content, our recommendation is to recount whenever the file is regenerated, and not to reuse the totals of the previous file.
12Who defines the profile and content of my file?+
The company sets the profile and content after hearing the state Finance Department. Block 9 only checks the count of what was decided, and the decision on the operation and the transmission is always your company's. DFSpro shows what the Guide says and proves that the system generates the file according to the choice.
Bring your generated file and we will check the count
The conversation starts with the file your SAP generates today: how many blocks it uses, how many establishments transmit and where the count has already failed. Also tell us which validator the team uses and who does the check before transmission, and bring the information for each period already closed.
Read also: ancillary obligations in SAP, Block K in SAP, Block H in SAP and tax calculation.