EFD-Reinf in SAP: from the withholding to the event, to the close and to DCTFWeb

It is a set of XML events, grouped in batches and signed, not a single TXT like the other SPED reports. The Developer Manual defines the batch as an XML that contains the XML of the events. Each event gets its own receipt after it is validated.

Series R-2000 covers social security contributions withheld or substituted. Series R-4000 covers withholding at source of income tax, CSLL, PIS and Cofins. Each series forms an independent movement in the period, with its own close: R-2099 for the first and R-4099 for the second.

Because the two withholdings come from different laws and acts. The manual gives the example of an invoice of BRL 10,000.00 with social security withholding of 11% and income tax of 1%: the R-2010 carries BRL 1,100.00 in the period of the invoice issue, and the R-4020 carries BRL 100.00 in the period of the payment or credit.

They are the closing events of each movement. The manual recommends sending them in an exclusive batch and only after receiving the receipts of all the periodic events of the period. While the R-2099 is being processed, EFD-Reinf does not receive events from that taxpayer and period, and those that arrive are rejected.

The rule is truncation at the second decimal place. In the manual's example, 11% on BRL 918.07 gives BRL 100.9877 and the correct withholding is BRL 100.98. To reduce rejections, the validation also accepts rounding up, within 1 cent. Whoever uses common rounding on all invoices must check this limit across the batch.

With the movement open, you send a new event with an amendment indicator. With the movement closed, you reopen it with the R-2098 or with the reopening R-4099 . Deletion uses the R-9000, with the event type and the receipt number. After reopening, a new close must be sent.

Events R-9001, R-9005, R-9011 e R-9015 are generated by EFD-Reinf itself from the periodic events and returned to the taxpayer, to report the taxes calculated and feed DCTFWeb. DCTFWeb is single and receives both series, and it is recommended to transmit it after the closes. Social security contributions are paid by a Darf issued by DCTFWeb.

No. Income from an employment relationship, settled directly by the employer, goes in eSocial and not in R-4010. That is the split between the two obligations, and it is why reconciling payroll with Reinf is a project topic.

The SAP Tax Declaration Framework for Brazil offers the EFD-Reinf report, run by transaction /TMF/REINF, which reports income paid and withholdings, social contribution not tied to labor and gross revenue. Before it, the help says to run the preprocessing and the taxpayer and proceeding event reports.

It scans electronic invoices and fills in the service type, to generate events R-2010 and R-2020, by configuration or by BAdI. It only supports invoices with one service item, and can only be repeated in the same period if the events were not yet sent to the tax authority. An invoice with several different service items needs its own handling.

The Messaging Framework help cites support for EFD-Reinf layout 1.3 in SP11, and the tax authority now operates layout 2.1.2 and the asynchronous model. How far your package goes depends on the installed version: confirm the version and the applicable support note, which requires a login.

The fine for failure or delay is 2% per calendar month on the taxes reported, capped at 20%. For incorrect or omitted information, it is BRL 20.00 per group of 10. The minimum fine is BRL 500.00. In addition, the difference shows up in DCTFWeb, which constitutes an acknowledgment of debt.

Yes. An accepted event means valid structure and content, not that the SAP withholding is the same. DCTFWeb is single and receives both series. Reconciling by event, by provider and by period is what avoids the difference later.

For facts from 01/01/2025, the Dirf is replaced by the events of series R-4000, by S-1210 and by S-2501 of eSocial. The page on the map of obligations summarizes the Dirf situation.

It created exemption type 12, used with income nature 12001, in force since 01/01/2026. The amount goes into the gross income of R-4010, which can have amounts without withholding up to BRL 50,000.00 in the month or amounts with withholding above that, at 10% on the taxable part. Since May 2026, type 5 with nature 10001 is no longer applicable.

Yes. The tax authority published EFD-Reinf Technical Note 03/2026 and new XSDs that replace the previous ones, keeping the versions, in production from July 2026, on a date to be announced; the SPED portal, read on 15/10/2026, does not give the effective date. The registration and interface test is on the page on Alphanumeric CNPJ in SAP.

DFSpro does not publish a price or a project timeline. Both depend on what the reading shows: series used, number of establishments, transmission method, SAP version and how much ABAP is needed. That is why the first step is to read a real month.

When the SAP withholding does not match the one declared, when events are rejected for precedence or for the close, when eSocial and Reinf disagree in DCTFWeb, or when the web service integration needs to move to the asynchronous model. The fine can reach 2% per calendar month on the taxes reported, capped at 20%.

Yes. DFSpro implements eSocial in SAP and does ABAP development and tax customization: service type, income nature, withholding by truncation, event generation and reconciliation reports with DCTFWeb. The overall architecture of the project stays with the integrator, and DFSpro works together with them.

The scope is the tax layer: data, rule, calculation and reconciliation. The signature uses the certificate of the same CNPJ or of an attorney with specific powers for EFD-Reinf, and stays with the company.

The method produces a matrix of differences, each with cause, where to look and fix; the fixes made at the source, which can include ABAP agreed beforehand; and recurring checks to run before the close. What is contracted is defined after the environment is read.

Not necessarily: SAP keeps the Reinf report in an ECC KBA and in TDF. The decision to migrate is a different conversation, covered in Clean Core fiscal.

Because withholding, service type and reconciliation with DCTFWeb have their own routine, which tends to sit between the project and the tax area. DFSpro works in the tax layer, and the overall architecture stays with the integrator. In each request it is agreed who changes what.

In the source data and in the reconciliation: service type, income nature, withholding by truncation, issue and payment dates and comparison with the receipts. Transmission stays with the system and the team that already do it.

It starts from a real month, with receipts and invoices the company already has. DFSpro follows a service invoice from the document to the receipt, the close and DCTFWeb, notes where a step only closes with a manual adjustment and shows which part of the environment to look at. The scope decision comes after that reading.

Take a real month and follow a service invoice from the document to the receipt: the service type, the withholding by truncation, the event, the batch, the protocol, the receipt, the close and the return R-9xxx. If any step needs a manual adjustment outside the system, the month is not supported. This is the script of the initial conversation with DFSpro.

A month with receipts of events R-2010 or R-4020, the matching service invoice, the SAP version and the current transmission method. Through the contact page the conversation starts from what you have.