CT-e and MDF-e in SAP: issuing, events, freight and the transport chain
Transport has its own documents: the transport waybill (CT-e, CT-e OS, GTV-e) says who provided the service, for whom and for how much, and the manifest (MDF-e) ties together the documents that are on the road. SAP has to issue, receive, link and post all of this together with the goods invoice.
From the document rule to the chain of subcontractors, from the cancellation and closing events to the ICMS credit on freight, from SD, MM and SAP TM to the 2026 technical notes of the tax reform.
Choose your entry point by your role
Four entry points, one per role, straight to the block that answers your question.
01Who issues
Carrier, shipper with its own fleet and logistics operator: model, issuing, MDF-e, events and contingency.
Go to the section02Who buys freight
Service taker and shipper: CT-e check, disagreement, ICMS credit and freight allocation.
Go to the section03IT and SAP
Monitors, SD and MM integration, SAP TM, ABAP and extension points.
Go to the section04Tax, accounting and reform
Posting, canceled and voided numbers in block D of the EFD, the August 3, 2026 deadline and the presumed credit for self-employed drivers.
Go to the sectionDirect links
Two documents, one load, several parties responsible
Anyone who moves goods in Brazil deals with four questions at the same time: who provided the service, who pays, in which vehicle the load travels, and how the tax authority sees the trip.
The CT-e says what was provided, the MDF-e says what is on the road, and SAP has to be the single source of truth for both, with the closing event, the ICMS credit and the posting all closing together.
The two documents
The CT-e (Conhecimento de Transporte Eletrônico, the electronic transport waybill, model 57) documents the provision of the transport service. The CT-e OS (model 67) covers other transport services, such as the transport of people and of valuables, and the GTV-e (model 64) is the electronic waybill for the transport of valuables.
The MDF-e (Manifesto Eletrônico de Documentos Fiscais, the electronic manifest of tax documents, model 58) links to the cargo unit the documents that are in transit, and its life cycle ends with the closing event.
What changes in SAP
In SAP, the difficulty is almost never in generating the XML. It is in connecting four worlds: the sales order and delivery (SD), the purchase order and goods receipt (MM), freight as a cost and as a credit (FI and tax) and, for those who use it, transport planning (SAP TM).
When these worlds do not talk to each other, the result is familiar: freight paid and not posted, ICMS credit taken without an authorized CT-e, a manifest open for weeks and a load stopped at inspection.
The view here is about issuing, MDF-e, freight and the transport chain. Receipt of the CT-e by the recipient, the lookup by NSU and the acknowledgment are in automatic inbound NF-e and CT-e, and the map of the five electronic documents is in electronic tax documents in SAP.
Where it fits
DFSpro's focus is the other side: who issues, who buys, and how SAP holds the end of the line.
Models, who uses them and what for
The table lists the transport documents SAP needs to know. The models and dates come from the norms and the official portal cited.
The Ajuste SINIEF 09/07 (the SINIEF agreement on the CT-e) created the CT-e, model 57, to replace the paper waybills (road, water, air, rail, multimodal and the transport service invoice for cargo). The Ajuste SINIEF 21/10 created the MDF-e, model 58, to replace the Cargo Manifest, model 25. The CT-e OS (model 67) and the GTV-e (model 64) appear in Joint Act RFB and CGIBS No. 4/2026.
| Document | Model | What it is for | Who issues | Source |
|---|---|---|---|---|
| CT-e | 57 | Documents the provision of cargo transport service, with legal validity through the qualified electronic signature and the authorization of use | Carrier | Aj. SINIEF 09/07, cl. 1 |
| CT-e OS | 67 | Other transport services, such as people and valuables | Service provider | Aj. SINIEF 09/07, cl. 1, §2-A (wording from 2016 to 2019); Joint Act 4/2026 |
| GTV-e | 64 | Electronic waybill for the transport of valuables | Valuables carrier | Joint Act RFB and CGIBS 4/2026, art. 1, VIII |
| Simplified CT-e | 57 | One CT-e for several services to the same service taker, by vehicle and trip, with different senders or recipients | Carrier | Aj. SINIEF 09/07, cl. 3-B |
| MDF-e | 58 | Links tax documents to the cargo unit during transport | Carrier, shipper with its own fleet or contracted self-employed driver | Aj. SINIEF 21/10, cls. 1 and 3 |
| DACTE and DAMDFE | n/a | Auxiliary documents that go with the cargo or make lookup easier, and may be shown in electronic form in the cases set by the norms | Generated by the issuer | Aj. 09/07, cls. 11 and 11-A; Aj. 21/10, cl. 11 |
The current texts of the two agreements, with the history of the wording of each clause, are in the Confaz copy. The CT-e portal handles the CT-e, CT-e OS and GTV-e together in the layout technical notes, which confirms that the three models coexist today.
Consignor, receiver, redispatch, subcontracting
Freight is rarely a single leg. The norm defines the parties that appear when the cargo changes hands, and each one changes what goes in the document and what SAP has to keep.
Ajuste SINIEF 09/07, clauses 2, 3, 3-A and 3-B: the issuer may name the consignor (who hands the cargo to the carrier) and the receiver (who receives it from the carrier); in subcontracting and redispatch, the consignor is the carrier or sender that hands over the cargo and the receiver is whoever receives it from the subcontracted or redispatched carrier; in multimodal transport, the linked service CT-e carries the key of the multimodal CT-e.
Subcontracting and redispatch
The issuer states, as an alternative, the CT-e key of the contracting carrier or the data of the previous transport document (cl. 3, §3). For SAP, this is a mandatory link between two documents.
Intermediate redispatch
When the consignor and the receiver are carriers of cargo that is not their own, filling in the sender and the recipient is not required and there can be a single CT-e for the same consignor and receiver (cl. 3, §§1 and 2).
Multimodal
The multimodal CT-e replaces the multimodal transport document, and the documents of the linked services must refer to it (cl. 1, §§7 to 9, and cl. 3-A).
Simplified CT-e
It requires, among other conditions, at least two senders or two recipients, cargo covered by an electronic invoice, start and end in the same state, the same CFOP and the same taxation (cl. 3-B, §1).
On the service taker side, clause 1, §6, of the CT-e agreement is direct: where issuing is mandatory, the service taker must require the CT-e and cannot accept another document in its place.
This has a practical effect for SAP. Freight payment should not be released without a linked authorized CT-e, and the carrier's supplier record must say which document is expected.
For the MDF-e, the rule is similar in spirit. In subcontracting, the manifest must be issued only by the carrier responsible for managing the service, the one that holds the information on the vehicle, the cargo, the driver and the logistics (Aj. SINIEF 21/10, cl. 3, §6). When the shipper uses its own, leased or self-employed vehicle, issuing is its job, and when the recipient is responsible for the transport and is registered to issue NF-e, the obligation falls on the recipient (cl. 3, §7).
The table of who is who in the chain must be in the process design before any setup: who issues the CT-e, who issues the MDF-e, who pays, who takes the credit. Most freight rework starts with a party that nobody drew, such as the third party that subcontracts and never appears in the purchase order.
From the transport request to the authorized CT-e
The issuing path is the same for almost every CT-e. What changes from one company to another is only who carries out each step and which record stays on file.
Registration
Registration in the state of the ICMS record and an ICP-Brasil certificate with the taxpayer's CNPJ (cls. 4 and 5).
Assembly
Data on the service taker, sender, recipient, amounts, taxes and transported documents in the MOC layout.
Transmission
Signed submission over the internet, under a security protocol, to the authorizer (cl. 6).
Authorization
Result: rejection or authorization of use. The authorization identifies the CT-e by CNPJ, number, series and environment.
Delivery to the service taker
File and protocol sent or made available for download (cl. 8, §9).
Storage and lookup
File kept by the carrier and the service taker for the retention period, with lookup by access key for at least 180 days (cls. 12 and 18).
Ajuste SINIEF 09/07, clause 8: the authorizer notifies the issuer of the rejection of the file (for a reception failure, authorship, registration, duplicate number, wrong CNPJ, CPF or state registration (IE), other layout failures, or a tax irregularity of the issuer) or of the authorization of use. Paragraph 8 says the authorization is the result of formal rules of the MOC and does not validate the tax information of the CT-e.
What the authorization does not prove
This last point weighs the most on posting. An authorized CT-e only proves that the form is correct. The service taker, before using the credit, must check the validity, the authenticity and the existence of the authorization of use (cl. 12, §1).
The issuer likewise needs its own content control, because the authorizer does not check whether the CFOP, the tax base and the rate are right.
Numbering
Numbering is just as strict. The taxpayer may use separate series, with no sub-series (cl. 5, §3), a break in the sequence requires a request to void the numbers by the 10th day of the following month (cl. 15) and canceled documents must be posted, with no monetary amounts (cl. 23). In SAP, this means a numbering monitor, gap handling and a voiding routine with an owner.
Manuals and technical notes
The manuals in force on the portal are the CT-e MOC, general overview version 4.0 (February 2023), with Annex I on layout and validation rules and Annex II on the DACTE, and the technical notes published since then.
The most recent one listed on the portal is NT 2026.004 v1.00, of 01/10/2026, on the adjustment of the CT-e, CT-e OS and GTV-e layouts. The version to implement must always be checked on the CT-e portal on the date of the project.
Cancel, correct, replace, prove delivery and disagreement
The CT-e lives on after authorization. Clause 18-A lists the events and clause 19 says who records them. SAP has to treat each one as a process trigger, not as a status message.
| Event | Who records it | Effect and limit | Source |
|---|---|---|---|
| Cancellation | Issuer | Within 168 hours of authorization and only if the service has not started; each request refers to a single CT-e; states may accept a late request | Aj. 09/07, cl. 14 |
| Correction letter (CC-e) | Issuer | Fixes errors in specific fields, within the limits of the general rule of the agreement; a paper letter is not allowed; the file must be made available to the service taker | Aj. 09/07, cl. 16 |
| Replacement CT-e | Issuer, after the service taker's event is recorded | Replaces amounts or a service taker entered wrongly; only one replacement per CT-e with an error, and it cannot be canceled; authorization within 60 days; service taker event within 45 days | Aj. 09/07, cls. 17 and 17-A |
| Complementary CT-e | Issuer | Records on the original that a complement exists (authorized and canceled) | Aj. 09/07, cl. 18-A, X and XI |
| Service provided in disagreement (and cancellation) | Service taker | The service taker itself states that the service provided differs from what is in the CT-e | Aj. 09/07, cl. 18-A, XXV and cl. 19, III |
| Proof of delivery (and cancellation) | Issuer | Records delivery by electronic capture and replaces the paper stub of the DACTE | Aj. 09/07, cl. 18-A, XXI, XXII and §5 |
| Failed delivery (and cancellation) | Carrier | Records that delivery was not possible, with the reason, and replaces the return reason on the back of the document | Aj. 09/07, cl. 18-A, XXIII, XXIV and §6 |
| MDF-e authorized or canceled, passage records | Automatic propagation or authorities | Show on the CT-e that it is part of a manifest, or the cancellation of the manifest, and the passages through inspection | Aj. 09/07, cl. 18-A, V to IX |
A detail that often goes unnoticed: transport events are propagated. The proof of delivery and the failed delivery of the CT-e become events on the referenced NF-e (this is in Ajuste SINIEF 07/05 and is covered in automatic inbound NF-e and CT-e).
For SAP, delivery of the freight also becomes proof of delivery of the sale, and posting the event on the sales document stops being manual work for logistics.
Correction by replacement deserves attention in the process. For the simplified CT-e, paragraph 3 of clause 3-B (Ajuste SINIEF 04/26, effective from 01.06.26) says that correcting an amount stated too low is done only by a replacement CT-e, and a complement is not allowed. An ERP that only knows how to issue a complement does not meet this case.
Write the table of the effect of each event in SAP: what each one causes in accounts payable, in the ICMS credit, in the delivery document and in posting. It is a one-page table that saves weeks of discussion.
When the authorizer does not answer
A communication failure is part of the operation. The norm says what to do, and SAP needs a written and tested script.
Ajuste SINIEF 09/07, clause 13: with no transmission or no answer, the taxpayer generates a new file stating contingency and transmits it to the Sefaz Virtual de Contingência (SVC), or, under the wording effective from 05.10.26 (Ajuste SINIEF 26/26 and 36/26), operates in offline contingency, with the DACTE on plain paper bearing the words "EMITIDO EM CONTINGÊNCIA OFF-LINE", transmitting as soon as the problem ends, within the MOC deadline. Reusing, in contingency, a number already transmitted in normal issuing is not allowed (§16).
- Contingency in the MDF-e In the MDF-e, contingency follows a similar logic: transmission right after the problems end, within the maximum of 168 hours from issuing, and a number transmitted in normal issuing cannot be reused (Ajuste SINIEF 21/10, cl. 12). The MDF-e is considered issued in contingency when the DAMDFE is printed in contingency, subject to a condition subsequent of authorization.
- Practical questions for SAP For SAP, there are three practical questions. Does the system tell CT-e and MDF-e issued in contingency apart from normal ones? Are the DACTE and DAMDFE in contingency part of the printing routine at dispatch?
- Document rejected on transmission And what happens to the contingency document that is rejected when it is transmitted: who regenerates it with the same number, without changing the tax variables, the issuer or service taker data, or the dates (cl. 13, §7)? Designing these answers is usually longer than the setup.
The manifest: when to issue, when to close
The MDF-e has its own rules and, for that reason, its own failures. Most manifests left open for weeks come from process, not from the system.
Ajuste SINIEF 21/10, clause 3: the MDF-e must be issued at the end of loading and before transport starts, by the CT-e issuer or by the NF-e issuer when transporting in own or leased vehicles or with a self-employed cargo driver; there must be one MDF-e for each state of unloading (§2, wording of Ajuste SINIEF 05/26, effective from 01.06.26), with the exceptions in §2-A; and it is also issued on transshipment, redispatch, subcontracting, change of vehicle or container, and inclusion of goods or documents (§1).
| Situation | Rule of the MDF-e agreement | Clause |
|---|---|---|
| Obligation | Set by schedule: interstate less-than-load cargo of CT-e issuers, more than one NF-e in an own or leased vehicle, full-load cargo and intercity transport, on defined dates; state legislation may bring the date forward | 17 |
| Who does not need it | Transport of a new unregistered vehicle when it is the means of transport and, for the NF-e issuer, MEI, those not registered in the ICMS record and rural producers in the cases set by the norm | 3-A |
| Cancellation | Within 24 hours of authorization, as long as the transport has not started | 13 |
| Closing | Event that ends the validity of the MDF-e, at the end of the last unloading; it can be done by the tax authority on its own initiative or, since 2023, by the carrier named in the document | 14, §§1 and 3 |
| Driver change | Driver inclusion event required whenever there is a change, replacement or inclusion | 14-A |
| Document inclusion | Event to add an NF-e after the trip has started, at the state's discretion, in intercity transport | 3, §9 and 14-B |
| Self-employed driver | Transport by a self-employed driver (TAC) can be covered at the same time by its own MDF-e and by the contractor's | 3, §10 |
The closing event is the most sensitive point. A manifest that is not closed stays valid, and the MDF-e portal keeps a lookup service for manifests that are not closed. The agreement provides for closing by the tax authority on its own initiative, but that is not a process plan: the routine must belong to the issuer.
The technical source of the MDF-e is the MOC general overview 3.00b (August 2022), with layout and rules in Annex I and the DAMDFE in Annex II, plus the later technical notes. The last note listed on the portal is NT 2026.001 v1.00, of 01/06/2026, which changes a validation rule.
The legislation listed on the portal includes Ajuste SINIEF 03/2026 and an act on the obligation to state the CIOT (the transport operation identifier code) in the manifest.
Nine events, four mandatory
The MDF-e agreement lists the events in clause 12-A. Clause 12-B requires the issuer to record four of them.
Cancellation
Voids the manifest before transport starts, within 24 hours
Who records it: Issuer.
Mandatory for the issuer: Yes.
Closing
Ends the validity at the end of the last unloading
Who records it: Issuer, tax authority or named carrier.
Mandatory for the issuer: Yes.
Driver inclusion
Records a change or inclusion of a driver
Who records it: Issuer.
Mandatory for the issuer: Yes.
Electronic tax document inclusion
Adds an NF-e after the trip has started in the allowed cases
Who records it: Issuer.
Mandatory for the issuer: Yes.
Passage record
Records the vehicle passing an inspection point
Who records it: Inspection authorities.
Mandatory for the issuer: No.
Transport service confirmation
Confirms the data of the transport contract recorded by the carrier
Who records it: Contractor.
Mandatory for the issuer: No.
Change of transport service payment
Adjusts payment amounts declared in relation to a contractor
Who records it: Issuer.
Mandatory for the issuer: No.
Closing by the carrier
Closes when the issuer did not
Who records it: Named carrier.
Mandatory for the issuer: No.
SVBA events
Events of the Sefaz Virtual da Bahia
Who records it: Signatories of the cooperation agreement.
Mandatory for the issuer: No.
The events of transport service confirmation and change of payment link the manifest to freight as a cost. For SAP, they suggest that the freight amount paid to the carrier can be recorded on the manifest itself and confirmed by the contractor, which also helps reconciliation. Those who work with self-employed drivers should study this data before deciding where SAP keeps the freight amount.
Where SAP issues, receives and links
What SAP's public documentation says, and what the company's tax layer needs to complete.
Where each document starts
The documentation of SAP Document and Reporting Compliance (DRC), with the electronic invoice option for Brazil, on the SAP help portal, lists the accepted documents and the tool for each one: inbound documents (NF-e and CT-e) are handled in the eDocument Cockpit (transaction EDOC_COCKPIT), outbound ones (NF-e, NFS-e and CT-e) in the NF-e and CT-e monitor (transaction J1BNFE) and the NF3-e in the eDocument Cockpit itself.
The outbound MDF-e
The outbound MDF-e appears differently: the text says the document is created by the client's own solution and processed by the method of the class CL_NFE_CLOUD_MDFE_PROCESSOR. The table of contents of the SAP ERP help also has a chapter on integrating the ERP with SAP TM.
Consequence for the design
This has a practical consequence for the design. The manifest, according to SAP's documentation, does not start from a ready-made monitor like the CT-e one: it starts from the solution the company builds.
Freight billing
Billing the transport service generates the outbound CT-e. A design question: does the CT-e start from billing or from a transport document?
Freight on purchases
The inbound CT-e arrives through the eDocument Cockpit and has to match the purchase order, the goods receipt and the transport document.
SAP TM
When there is transport planning, the TM freight becomes a freight order and settlement, and the integration with the ERP has to carry the tax document.
Tax extension
Manifest through a custom solution, allocation rules and content checks before sending to the authorizer.
The role of ABAP
This solution has to assemble the cargo, vehicle, driver and linked document data, respect the rule of one manifest per state of unloading, and call the processor. This is where ABAP development and tax customization come in, the part of the work that DFSpro does.
What is new in S/4HANA
For S/4HANA, the what's-new topics of SAP's functional localizations include, among the Brazil subjects, fields added to the CT-e BAPI structure, a link of the CT-e to financial payment transactions, classification of government entity on the CT-e, support for the simplified CT-e and fields for mapping NF-e and CT-e XML.
Reference note for the reform
The tax reform reference note that the documentation cites is SAP Note 3561376.
For the choice between the old GRC NF-e and the DRC, the specialty from GRC NF-e to DRC covers the decision. For the use of APIs and SAP BTP in the integration with carriers and freight platforms, see tax integration with SAP BTP and API.
Define, before any setup, which SAP document is the trigger of each CT-e and each MDF-e, who owns the link to the goods invoice and where the access key is stored. This trio is what supports posting later.
Credit, reversal and allocation of freight in practice
Freight enters the tax calculation in two places: as a credit for whoever buys it and as a debit for whoever provides it. The base rule is in Complementary Law 87/1996 (the Kandir Law).
Three consequences for SAP, all tax-related and about master data.
Credit
First: the CT-e shows the tax, but the right to the credit belongs to the service taker and depends on the activity, the destination of the freight and state legislation. The credit should not be created automatically from the XML.
Reversal
Second: the reversal requires knowing whether the later outbound sale was taxed, and that depends on a link between the freight and the sales operation.
Allocation
Third: the freight allocation between invoices of the same trip, between items of an invoice and between cost centers is a business rule that the law does not settle on its own.
Complementary Law 87/1996, art. 20: the taxpayer has the right to credit the tax previously charged on operations that resulted in the entry of goods or the receipt of interstate and intercity transport services or of communication. Paragraph 1 excludes entries or services from exempt or untaxed operations and those unrelated to the establishment's activity, and art. 21 requires reversal when the service taken is used for a purpose unrelated to the activity, or the later outbound sale is exempt or untaxed, with exceptions for exports.
Guidance on allocation
DFSpro advises, without the force of a norm, that allocation have a written criterion (weight, value or volume), that the CT-e be linked to the goods invoices it carries and that the result feed the material cost and the posting of transport in the EFD, covered in ancillary obligations and SPED.
In tax setup and in tax master data are the data that decide CFOP, CST and the right to credit on freight at entry.
Self-employed driver
For those who work with a self-employed driver who is an individual, the tax reform creates a mechanism of its own, covered next.
What the reform changed in transport
Transport entered the calendar of tax documents of the reform.
Joint Act RFB and CGIBS No. 4/2026, article 1, published on the CT-e portal on 31/07/2026: the start of the obligation to issue, with the IBS and CBS fields, the electronic documents set out in the regulations of the tax and the contribution applies to taxable events from August 3, 2026, and reaches the CT-e (model 57), the CT-e OS (model 67), the MDF-e (model 58), the GTV-e (model 64), the BP-e not covered by the exceptions, the NF-e and the NFC-e.
For Simples Nacional taxpayers (the small-business tax regime), the date is January 1, 2027 (§1). The semi-urban or metropolitan BP-e and the air BP-e have a date of December 1, 2026.
| Topic | What the norm says | Source |
|---|---|---|
| Rejection for missing IBS and CBS | Technical notes 2026.002 for CT-e, BP-e, NF3e and NFCom define the validation rule that requires IBS and CBS information (rejection 310), switched on in the production environment on 03/08/2026 | News from the MDF-e portal (SVRS) on NTs 2026.002 |
| Document total | The rule that makes the field vTotDFe mandatory whenever the IBSCBS group is present results in rejection 360 | SVRS portal notice on version 1.13 of NT 2025.001 |
| Split payment fields | Technical notes clarify that there is no requirement to fill in or use the split payment fields in production in 2026, which are preparatory; the dates will come through a regulatory instrument | SVRS portal notice |
| CT-e technical notes | Series 2025.001 (RTC, versions 1.00 to 1.14b until 30/04/2026), 2026.001 (link to the payment transaction), 2026.002 (v1.01 on 04/08/2026) and 2026.004 v1.00 (01/10/2026) | CT-e portal, Documents, Technical Notes |
| Joint Act RFB and CGIBS No. 8/2026 | Approves several technical documents, published on 01/10/2026 | CT-e portal, notice of 02/10/2026 |
Presumed credit for the self-employed driver
There is also a credit rule that changes the math for those who hire self-employed drivers. Complementary Law 214/2025, art. 169, allows the taxpayer in the regular regime to take presumed credit of IBS and CBS on purchases of cargo transport service from a self-employed driver who is an individual non-taxpayer or an MEI.
The electronic tax document of the purchase must show the transaction amount, the presumed credit amount and the net amount, and the percentages are set by a joint act of the Minister of Finance and the IBS Steering Committee, published each year by September and valid from January 1 of the following year (§§2 to 4).
The credit does not apply when the freight is included in the transaction amount (§1, II).
Alphanumeric CNPJ
As for the alphanumeric CNPJ, which affects the CT-e and the MDF-e, the specialty alphanumeric CNPJ covers the impact: the SVRS test environment began to offer an alphanumeric test CNPJ for CT-e, CT-e OS, GTV-e, MDF-e and other documents.
The consequence for SAP is about master data and process: the self-employed driver's record has to say what the driver is, the purchase document has to show the three amounts, and the credit engine has to look up the percentage in force. This is the layer of tax setup and of tax master data.
Ten CT-e and MDF-e failures and how to handle each one
Recurring failures in SAP systems.
Manifest open for weeks
Likely cause: Closing not carried out by the process. Check: Closing routine at the end of the last unloading and the lookup of manifests not closed.
Rejection for missing IBS and CBS
Likely cause: Layout without the IBSCBS group or without the document total. Check: Field mapping and technical note version in the issuer.
Authorized CT-e, undue credit
Likely cause: Credit taken from the XML alone. Check: Rule for the right to freight credit and reversal.
Freight paid without a linked CT-e
Likely cause: Payment released without an authorization check. Check: Payment block by valid access key.
Numbering gap
Likely cause: Process failure or contingency. Check: Voiding request made by the 10th day of the following month.
Correction letter refused
Likely cause: Field outside what the norm allows to correct. Check: Use replacement when it affects the amount or the service taker.
MDF-e with mixed unloading states
Likely cause: One manifest for several states. Check: Rule of one MDF-e per state of unloading.
Proof of delivery missing
Likely cause: Carrier without electronic capture. Check: Delivery event and propagation to the NF-e.
Replacement rejected
Likely cause: 60-day deadline passed or a second replacement. Check: Control of the deadline and of the limit of one replacement per CT-e.
Contingency document with no return
Likely cause: Later transmission not carried out. Check: Contingency queue with an owner and a deadline.
Freight readiness in SAP in twenty points
Four blocks, five items each. An honest answer shows where the process depends on one person.
Issuing
- Registration and certificate valid for each CNPJ
- Right model for each service (57, 67, 64)
- Series and numbering with gap control
- Contingency routine tested
- Technical note version in force checked on the portal
Chain and MDF-e
- Chain parties drawn (consignor, receiver, subcontractor)
- One MDF-e per state of unloading
- Closing with an owner and a deadline
- Driver change recorded
- Lookup of manifests not closed running
Tax
- Right to freight credit defined by rule
- Reversal linked to the later outbound sale
- Canceled and voided numbers posted with no amount
- Transport posting in the EFD checked
- Freight allocation with a written criterion
Reform
- IBS and CBS fields on the CT-e and the MDF-e
- Document total filled in
- Self-employed driver's record with the correct nature
- Presumed credit percentage looked up by validity period
- Plan for the Simples Nacional in 2027
Development and the tax layer of freight
DFSpro's work on this topic joins the tax rule and ABAP development.
- DFSpro develops in ABAP and customizes the tax layer. In freight, this means turning the rule in the text into a solution: the routine that builds the manifest per state of unloading, the validation that stops freight from being paid without an authorized CT-e, the table of the effect of each event and the allocation with a written criterion.
- DFSpro does not replace the integrator in the overall architecture of the SAP project and works alongside it.
- The conversation starts with a diagnostic of what the system does today with CT-e and MDF-e, using the same governance method as the other specialties.
- See also tax setup, tax master data and ancillary obligations and SPED.
One trip, three documents, one routine
The case was built only to show the method, with no relation to any real client.
- 01
An industrial company ships cargo from a plant in Paraná to two customers, in Santa Catarina and in São Paulo, in a vehicle hired from a carrier that subcontracts the last leg. The carrier issues the CT-e (or the simplified CT-e, if it meets the conditions) and the manifest.
- 02
Since there are two states of unloading, the rule calls for two manifests. The company, as the service taker, should not release payment before the CT-e is authorized, should not take credit from the XML and should keep the access key with the delivery document.
- 03
At the time of delivery, the carrier records the proof of delivery, which propagates to the NF-e. If the cargo comes back, it records the failed delivery. If the carrier got the service taker wrong, the original service taker records the disagreement event and the carrier issues the replacement CT-e within 60 days.
- 04
If the manifest is not closed, the closing becomes an open item with an owner. At each step there is an event, and for each event there is an effect in SAP. The routine is to write those effects down and test them.
Sources for each fact
Layouts and versions must be checked on the portal on the date of the project.
Technical notes are cited by the title and publication date listed on the portal.
Confaz
Others
- CT-e portal: main pagenotices, Technical Notes and Manuals (Federal Revenue and ENCAT)
- Joint Act RFB and CGIBS No. 4/2026published in notice 176 of the CT-e portal (RFB and CGIBS)
- MDF-e portal: homelegislation, documents and frequently asked questions (SEFAZ Virtual RS)
- MDF-e portal notices(NTs 2026.002, rejection 310, vTotDFe) (SEFAZ Virtual RS)
Federal Revenue and SPED
Legislation
Blog articles about CT-e and freight
Frequently asked questions about CT-e and MDF-e
01What is the difference between CT-e and MDF-e?+
The CT-e (model 57) documents the provision of the transport service, with amount, service taker and taxes. The MDF-e (model 58) links to the cargo unit the tax documents that are in transit, and ends with the closing event (Ajuste SINIEF 09/07 and Ajuste SINIEF 21/10).
02What are CT-e OS and GTV-e?+
The CT-e OS (model 67) is the waybill for other transport services, and the GTV-e (model 64) is the electronic Waybill for the Transport of Valuables. Both appear in Joint Act RFB and CGIBS No. 4/2026 and in the technical notes of the CT-e portal.
03What is the deadline to cancel a CT-e?+
The issuer may request cancellation within no more than 168 hours after authorization, as long as the transport service has not started (Ajuste SINIEF 09/07, clause 14). States may accept a late request.
04And the cancellation of the MDF-e?+
It may be requested within 24 hours of the authorization of use, as long as the transport has not started (Ajuste SINIEF 21/10, clause 13).
05When must the MDF-e be closed?+
At the end of the last unloading described in the document. If the issuer does not close it, the tax authority can close it on its own initiative and, since 2023, the carrier named in the document can also close it, taking responsibility for the effects (clause 14).
06Do I need one MDF-e per state?+
Yes, the rule is a separate MDF-e for each state of unloading, with exceptions, such as mixed cargo of own and third-party goods and transport by a self-employed driver (clause 3, §§2 and 2-A, Ajuste SINIEF 21/10).
07How do I correct a CT-e with a wrong amount?+
A correction letter is not used to change the variables that determine the tax. Clause 17 provides for the replacement CT-e, after an event recorded by the service taker within 45 days, with authorization within 60 days and a single replacement per CT-e with an error.
08Can the service taker take ICMS credit on freight from the CT-e alone?+
Not automatically. LC 87/1996, art. 20, gives the right to credit the tax charged on receiving interstate and intercity transport services, but excludes exempt, untaxed and unrelated services, and art. 21 provides for reversal. The service taker must also check the authorization of use before using the credit (cl. 12, §1, of Ajuste SINIEF 09/07).
09Does the CT-e authorization confirm that the tax is correct?+
No. Clause 8, §8, says the authorization is the result of formal rules and does not validate the tax information of the CT-e.
10What is the simplified CT-e?+
It is a single CT-e for several services to the same service taker, by vehicle and trip, with different senders or recipients, subject to the conditions of clause 3-B, such as electronic invoices, start and end in the same state, the same CFOP and the same taxation. A correction of an amount that is too low is made by a replacement CT-e.
11When do the CT-e and the MDF-e start to require IBS and CBS?+
Joint Act RFB and CGIBS No. 4/2026 sets August 3, 2026 for CT-e, CT-e OS, MDF-e and GTV-e, and January 1, 2027 for Simples Nacional taxpayers. Technical notes 2026.002 switched on the validation rule (rejection 310) in production on 03/08/2026.
12Is there a credit for those who hire a self-employed driver?+
LC 214/2025, art. 169, allows a presumed credit of IBS and CBS on purchases of cargo transport from a self-employed driver who is an individual non-taxpayer or an MEI, with percentages set by joint act and a document that shows the transaction, the credit and the net amount.
13How does SAP handle the MDF-e?+
In the SAP DRC documentation for Brazil, the outbound MDF-e is created by the client's own solution and processed by the method of the class CL_NFE_CLOUD_MDFE_PROCESSOR, unlike the CT-e, which is processed in the NF-e and CT-e monitor.
14Where does SAP process the inbound and outbound CT-e?+
According to SAP's documentation, the inbound CT-e is handled in the eDocument Cockpit (EDOC_COCKPIT) and the outbound one in the NF-e and CT-e monitor (J1BNFE). Check the documentation of the version in use.
15Does DFSpro do freight development in SAP?+
Yes. DFSpro does ABAP development and tax customization, and works alongside the integrator without replacing it in the overall architecture.
16Where do I start?+
With three questions: who issues and who closes the MDF-e, whether freight payment requires a linked authorized CT-e, and what the table of the effect of each event in SAP is. Through the contact channel, your case can be discussed.
Find out how your system issues, closes and credits freight
The first step is to map who issues the CT-e and the MDF-e, who closes the manifest and what the effect of each event is on payment and on credit. The contact channel is there to deal with your situation.
To go deeper: automatic inbound NF-e and CT-e, electronic tax documents, ancillary obligations and SPED and tax setup.