SAP Business One in Brazil: Nota Fiscal, NF-e and CNPJ

SAP Business One runs in Brazil on an official SAP localization, and it is one of the most detailed localizations SAP ships: the Nota Fiscal sits inside the normal sales and purchasing documents, a tax engine calculates ICMS, IPI, PIS, COFINS and ISS, and the SPED files come out of the system. What the localization does not do on its own is talk to SEFAZ. This page explains where the line runs, which tables hold the Brazilian data, what changed in 2026 with the alphanumeric CNPJ and the IBS/CBS tax reform, and gives a SQL query that finds broken CNPJ and CPF numbers before SEFAZ rejects a note for them.

I am Zain Abbas, a SAP Business One developer with more than 7 years of SAP B1 work for companies in 13 countries. Brazil is not one of them, and I say that up front. My e-invoicing integrations are for Saudi Arabia, Ecuador, Guatemala, El Salvador and Panama, all clearance-model countries where the tax authority authorises each document before it is valid. Brazil invented that model with the NF-e, so the data-quality and add-on lessons carry over. The Brazilian rules on this page come from SAP’s documentation, the Receita Federal and the national NF-e portal, linked at the end.

What does the Brazil localization of SAP Business One cover?

You choose Brazil as the localization when the company database is created, and it cannot be changed later. SAP’s Localization for Brazil help for release 10.0 covers these areas:

Three facts from that documentation matter more than the rest when you plan a project.

First, the Electronic Invoicing topic for Brazil is short. It says Brazilian law requires an NF-e for every movement of goods or services, even when exempt, and then lists SAP Notes (1757955, 1922450, 1978114, 2004874, 2029968, 2980052, 3011261). It does not describe a SEFAZ connector, a certificate setup or an authorisation status flow inside SAP Business One. I checked on 11 November 2026.

Second, a separate topic, Fields for External Add-On Reading, says SAP added fields to the item master, business partner master, company details and the nota fiscal marketing documents “to standardize the usage for external add-on reading” (SAP Note 1715284). That is SAP describing the architecture: SAP Business One owns the fiscal data, an add-on owns the transmission.

Third, the Electronic Document Monitor exists for Brazil, but SAP’s Brazil page for it documents only two buttons, Approve and Reject, to record what the business partner did with a document. The tracking of SEFAZ authorisation, rejection codes, cancellation events and the correction letter (CC-e) is the add-on’s job, usually stored in user-defined fields on OINV and its sister tables.

How does an NF-e get from SAP Business One to SEFAZ?

The partner add-on differs from company to company; the steps do not, because the NF-e rules on the national portal fix them:

1. The user adds the outgoing document (A/R invoice, delivery, goods return or A/P credit memo). SAP Business One takes the next Nota Fiscal number from the sequence assigned to that document type and branch, and calculates the taxes through tax code determination and the tax engine.
2. The add-on builds the XML in the NF-e layout (model 55; NFC-e is model 65): issuer and recipient from the company details and the INV12 fiscal IDs, items with NCM, CFOP and CST from INV1, tax groups for ICMS, IPI, PIS and COFINS from the tax lines, and from 2026 the IBS/CBS group. The 44-character access key (chave de acesso) contains the state code, year and month, the issuer’s CNPJ, the model, series and number.
3. The add-on signs the XML with the company’s ICP-Brasil certificate (A1 file or A3 token) and sends it to the SEFAZ of the issuer’s state, or to a virtual SEFAZ for states that use one.
4. SEFAZ authorises or rejects. Only an authorised NF-e is a valid document; the goods can move with the printed DANFE. A rejection comes back with a numeric code and a message, and the note must be corrected and sent again with the same number.
5. The add-on writes back the access key, protocol number and status to the document, stores the authorised XML (the issuer must keep it for the legal period) and emails it to the buyer.
6. Events after authorisation run through the add-on too: cancellation (generally within 24 hours of authorisation, later only where the state allows it), the CC-e correction letter for errors that do not change taxes, values or parties, and inutilização to void unused numbers in a sequence.

Inbound works the other way. CRD7 has a column AToRetrNFe, “Authorization to Retrieve NFe from SEFAZ”, and SefazDate, the date of the last update from SEFAZ, which tells you SAP expects business partner data and NF-e downloads to be synchronised with SEFAZ by something outside the core. Good add-ons pick up the supplier’s NF-e XML by the company’s CNPJ and create a draft goods receipt PO or A/P invoice from it.

What carries over from my clearance-model projects in Ecuador, Guatemala, El Salvador and Panama:

• One numbering source. The Nota Fiscal number must come from the SAP Business One sequence, never from the add-on. If two systems hand out numbers, gaps appear, and in Brazil each gap needs an inutilização request.
• Map the tax codes with the contador before anyone writes XML. A SAP tax code is a combination of tax types and rates; the NF-e wants CST per tax, CFOP per line, the ICMS origin digit and, for ICMS-ST, the base and margin. Put the SAP view and the XML view side by side for every real scenario (sale inside the state, sale to another state, sale to a final consumer in another state, return, remessa) and get it signed off.
• Fix master data before the pilot. A wrong CNPJ, a missing I.E. on a contributor, an item without NCM or a line without CFOP each produce a SEFAZ rejection, one note at a time, while the truck waits. The queries below find them in minutes.

What changed in 2026: alphanumeric CNPJ and the IBS/CBS reform

Two Brazilian changes this year reach straight into SAP Business One data.

Alphanumeric CNPJ. Instrução Normativa RFB 2.229 of 15 October 2024 introduced CNPJs whose first 12 positions can hold the letters A to Z as well as digits. The Receita Federal assigns them only to new registrations from July 2026; existing CNPJs stay valid and unchanged. The Receita’s schedule shows the CNPJ systems going into production on 27 July 2026 and the first alphanumeric CNPJ issued on 31 July 2026. The two check digits stay numeric and are still computed with modulus 11, but each character now counts as its ASCII code minus 48, so 0 to 9 keep their values and A counts as 17. SAP’s own Fiscal IDs help page already uses the example 12.ABC.345/01DE-35, and that example passes the new check: I verified it with the algorithm in the query below.

What breaks in practice: user-defined fields typed as numeric, add-ons that strip everything except digits before sending the XML, Crystal Reports formulas that format the CNPJ with a digit-only mask, integration code that casts CNPJ to BIGINT, and validation queries copied from 2015 forum posts. The access key of an NF-e issued by a company with an alphanumeric CNPJ also contains those letters, so any field or index that stores the chave de acesso as a number needs to change too.

IBS and CBS. Lei Complementar 214/2025 created the CBS (federal) and IBS (states and municipalities), with 2026 as a test year. Nota Técnica 2025.002-RTC adds an IBS/CBS group with its own CST and classification codes to the NF-e and NFC-e. The SEFAZ rule that rejects a note without that group has moved between versions of the note and was postponed for production in the later ones, while the obligation to report stays; check the current version on the national NF-e portal before you commit to a date. For SAP Business One this is an add-on release plus configuration: new tax types or user-defined fields for the IBS/CBS codes on items and tax codes, and a decision on whether the test-year amounts are calculated by the tax engine or only filled in the XML by the add-on. Ask your add-on vendor which NT version their current build supports.

How do you find invalid CNPJ and CPF numbers in SAP Business One?

CRD7 holds one row per business partner, address and address type (S for ship-to, B for bill-to), with generic columns TaxId0 to TaxId14. On a Brazil database the Fiscal IDs window writes CNPJ to TaxId0 and Inscrição Estadual to TaxId1, as a SAP Community answer already described for release 8.8. The column that holds CPF follows the order of fields in the window; do not assume it, measure it. This first query shows, per column, how many values look like a CNPJ (14 characters) or a CPF (11 digits):

-- SQL Server: which CRD7 column holds which Brazilian ID
SELECT 'TaxId0' AS Col, SUM(CASE WHEN LEN(X) = 14 THEN 1 ELSE 0 END) AS Len14, SUM(CASE WHEN LEN(X) = 11 THEN 1 ELSE 0 END) AS Len11
FROM (SELECT REPLACE(REPLACE(REPLACE(REPLACE(ISNULL(TaxId0, ''), '.', ''), '/', ''), '-', ''), ' ', '') AS X FROM CRD7) A
UNION ALL
SELECT 'TaxId4', SUM(CASE WHEN LEN(X) = 14 THEN 1 ELSE 0 END), SUM(CASE WHEN LEN(X) = 11 THEN 1 ELSE 0 END)
FROM (SELECT REPLACE(REPLACE(REPLACE(ISNULL(TaxId4, ''), '.', ''), '-', ''), ' ', '') AS X FROM CRD7) B;
-- Repeat the block for TaxId1..TaxId3 and TaxId5 if TaxId4 shows no 11-digit values.

The main query then checks every active business partner. It accepts both the old numeric and the new alphanumeric CNPJ, rejects repeated-digit fillers such as 00000000000000 and 11111111111, and reports the problem in words. Change F.TaxId4 if the first query put CPF in another column.

-- SQL Server: invalid CNPJ (numeric or alphanumeric) and CPF in BP fiscal IDs
WITH F AS (
    SELECT C.CardCode, C.CardName, C.CardType, F.Address, F.AddrType,
           UPPER(REPLACE(REPLACE(REPLACE(REPLACE(ISNULL(F.TaxId0, ''), '.', ''), '/', ''), '-', ''), ' ', '')) AS Cnpj,
           REPLACE(REPLACE(REPLACE(ISNULL(F.TaxId4, ''), '.', ''), '-', ''), ' ', '') AS Cpf
    FROM OCRD C
    JOIN CRD7 F ON F.CardCode = C.CardCode
    WHERE C.frozenFor = 'N'
), W AS (   -- position, weight for DV1, weight for DV2
    SELECT * FROM (VALUES (1,5,6),(2,4,5),(3,3,4),(4,2,3),(5,9,2),(6,8,9),(7,7,8),
                          (8,6,7),(9,5,6),(10,4,5),(11,3,4),(12,2,3),(13,0,2)) AS W(i, w1, w2)
), CN AS (
    SELECT F.CardCode, F.Address, F.AddrType,
           SUM((ASCII(SUBSTRING(F.Cnpj, W.i, 1)) - 48) * W.w1) % 11 AS R1,
           SUM((ASCII(SUBSTRING(F.Cnpj, W.i, 1)) - 48) * W.w2) % 11 AS R2
    FROM F CROSS JOIN W
    WHERE F.Cnpj LIKE REPLICATE('[0-9A-Z]', 12) + '[0-9][0-9]'
    GROUP BY F.CardCode, F.Address, F.AddrType
), P AS (   -- CPF positions 1..10 with weights for DV1 (10..2) and DV2 (11..2)
    SELECT * FROM (VALUES (1,10,11),(2,9,10),(3,8,9),(4,7,8),(5,6,7),(6,5,6),(7,4,5),
                          (8,3,4),(9,2,3),(10,0,2)) AS P(i, w1, w2)
), CP AS (
    SELECT F.CardCode, F.Address, F.AddrType,
           SUM(CAST(SUBSTRING(F.Cpf, P.i, 1) AS INT) * P.w1) * 10 % 11 % 10 AS D1,
           SUM(CAST(SUBSTRING(F.Cpf, P.i, 1) AS INT) * P.w2) * 10 % 11 % 10 AS D2
    FROM F CROSS JOIN P
    WHERE F.Cpf LIKE REPLICATE('[0-9]', 11)
    GROUP BY F.CardCode, F.Address, F.AddrType
)
SELECT F.CardCode, F.CardName, F.CardType, F.Address, F.AddrType, F.Cnpj, F.Cpf,
       CASE
         WHEN F.Cnpj = '' AND F.Cpf = '' THEN 'No CNPJ and no CPF'
         WHEN F.Cnpj <> '' AND CN.CardCode IS NULL THEN 'CNPJ has wrong length or characters'
         WHEN F.Cnpj <> '' AND F.Cnpj = REPLICATE(LEFT(F.Cnpj, 1), 14) THEN 'CNPJ is a repeated-digit filler'
         WHEN F.Cnpj <> '' AND (SUBSTRING(F.Cnpj, 13, 1) <> CAST(CASE WHEN CN.R1 < 2 THEN 0 ELSE 11 - CN.R1 END AS CHAR(1))
                            OR SUBSTRING(F.Cnpj, 14, 1) <> CAST(CASE WHEN CN.R2 < 2 THEN 0 ELSE 11 - CN.R2 END AS CHAR(1)))
              THEN 'CNPJ check digits wrong'
         WHEN F.Cpf <> '' AND CP.CardCode IS NULL THEN 'CPF has wrong length or characters'
         WHEN F.Cpf <> '' AND F.Cpf = REPLICATE(LEFT(F.Cpf, 1), 11) THEN 'CPF is a repeated-digit filler'
         WHEN F.Cpf <> '' AND (SUBSTRING(F.Cpf, 10, 1) <> CAST(CP.D1 AS CHAR(1))
                           OR SUBSTRING(F.Cpf, 11, 1) <> CAST(CP.D2 AS CHAR(1)))
              THEN 'CPF check digits wrong'
       END AS Problem
FROM F
LEFT JOIN CN ON CN.CardCode = F.CardCode AND CN.Address = F.Address AND CN.AddrType = F.AddrType
LEFT JOIN CP ON CP.CardCode = F.CardCode AND CP.Address = F.Address AND CP.AddrType = F.AddrType
WHERE NOT (F.Cnpj = '' AND F.Cpf = '' AND F.Address <> '')   -- empty extra address rows are normal
ORDER BY Problem DESC, F.CardCode;

Rows with Problem = NULL are fine; filter them out once you trust the query. In the SAP Business One query manager, wrap it as SELECT * FROM ( ... ) Q WHERE Q.Problem IS NOT NULL after moving the CTEs into derived tables, because the query manager does not accept a leading WITH on every version.

The same logic on SAP HANA, where LIKE has no character classes and the column names must be quoted:

-- SAP HANA: invalid CNPJ (numeric or alphanumeric) and CPF in BP fiscal IDs
WITH F AS (
    SELECT C."CardCode", C."CardName", C."CardType", F."Address", F."AddrType",
           UPPER(REPLACE_REGEXPR('[./ -]' IN IFNULL(F."TaxId0", '') WITH '')) AS "Cnpj",
           REPLACE_REGEXPR('[. -]' IN IFNULL(F."TaxId4", '') WITH '') AS "Cpf"
    FROM "OCRD" C
    JOIN "CRD7" F ON F."CardCode" = C."CardCode"
    WHERE C."frozenFor" = 'N'
), W AS (
    SELECT 1 AS "i", 5 AS "w1", 6 AS "w2" FROM DUMMY UNION ALL SELECT 2, 4, 5 FROM DUMMY UNION ALL
    SELECT 3, 3, 4 FROM DUMMY UNION ALL SELECT 4, 2, 3 FROM DUMMY UNION ALL SELECT 5, 9, 2 FROM DUMMY UNION ALL
    SELECT 6, 8, 9 FROM DUMMY UNION ALL SELECT 7, 7, 8 FROM DUMMY UNION ALL SELECT 8, 6, 7 FROM DUMMY UNION ALL
    SELECT 9, 5, 6 FROM DUMMY UNION ALL SELECT 10, 4, 5 FROM DUMMY UNION ALL SELECT 11, 3, 4 FROM DUMMY UNION ALL
    SELECT 12, 2, 3 FROM DUMMY UNION ALL SELECT 13, 0, 2 FROM DUMMY
), CN AS (
    SELECT F."CardCode", F."Address", F."AddrType",
           MOD(SUM((ASCII(SUBSTRING(F."Cnpj", W."i", 1)) - 48) * W."w1"), 11) AS "R1",
           MOD(SUM((ASCII(SUBSTRING(F."Cnpj", W."i", 1)) - 48) * W."w2"), 11) AS "R2"
    FROM F CROSS JOIN W
    WHERE F."Cnpj" LIKE_REGEXPR '^[0-9A-Z]{12}[0-9]{2}$'
    GROUP BY F."CardCode", F."Address", F."AddrType"
), P AS (
    SELECT 1 AS "i", 10 AS "w1", 11 AS "w2" FROM DUMMY UNION ALL SELECT 2, 9, 10 FROM DUMMY UNION ALL
    SELECT 3, 8, 9 FROM DUMMY UNION ALL SELECT 4, 7, 8 FROM DUMMY UNION ALL SELECT 5, 6, 7 FROM DUMMY UNION ALL
    SELECT 6, 5, 6 FROM DUMMY UNION ALL SELECT 7, 4, 5 FROM DUMMY UNION ALL SELECT 8, 3, 4 FROM DUMMY UNION ALL
    SELECT 9, 2, 3 FROM DUMMY UNION ALL SELECT 10, 0, 2 FROM DUMMY
), CP AS (
    SELECT F."CardCode", F."Address", F."AddrType",
           MOD(MOD(SUM(TO_INTEGER(SUBSTRING(F."Cpf", P."i", 1)) * P."w1") * 10, 11), 10) AS "D1",
           MOD(MOD(SUM(TO_INTEGER(SUBSTRING(F."Cpf", P."i", 1)) * P."w2") * 10, 11), 10) AS "D2"
    FROM F CROSS JOIN P
    WHERE F."Cpf" LIKE_REGEXPR '^[0-9]{11}$'
    GROUP BY F."CardCode", F."Address", F."AddrType"
)
SELECT F."CardCode", F."CardName", F."CardType", F."Address", F."AddrType", F."Cnpj", F."Cpf",
       CASE
         WHEN F."Cnpj" = '' AND F."Cpf" = '' THEN 'No CNPJ and no CPF'
         WHEN F."Cnpj" <> '' AND CN."CardCode" IS NULL THEN 'CNPJ has wrong length or characters'
         WHEN F."Cnpj" <> '' AND F."Cnpj" = RPAD('', 14, LEFT(F."Cnpj", 1)) THEN 'CNPJ is a repeated-digit filler'
         WHEN F."Cnpj" <> '' AND (SUBSTRING(F."Cnpj", 13, 1) <> TO_VARCHAR(CASE WHEN CN."R1" < 2 THEN 0 ELSE 11 - CN."R1" END)
                              OR SUBSTRING(F."Cnpj", 14, 1) <> TO_VARCHAR(CASE WHEN CN."R2" < 2 THEN 0 ELSE 11 - CN."R2" END))
              THEN 'CNPJ check digits wrong'
         WHEN F."Cpf" <> '' AND CP."CardCode" IS NULL THEN 'CPF has wrong length or characters'
         WHEN F."Cpf" <> '' AND F."Cpf" = RPAD('', 11, LEFT(F."Cpf", 1)) THEN 'CPF is a repeated-digit filler'
         WHEN F."Cpf" <> '' AND (SUBSTRING(F."Cpf", 10, 1) <> TO_VARCHAR(CP."D1")
                             OR SUBSTRING(F."Cpf", 11, 1) <> TO_VARCHAR(CP."D2"))
              THEN 'CPF check digits wrong'
       END AS "Problem"
FROM F
LEFT JOIN CN ON CN."CardCode" = F."CardCode" AND CN."Address" = F."Address" AND CN."AddrType" = F."AddrType"
LEFT JOIN CP ON CP."CardCode" = F."CardCode" AND CP."Address" = F."Address" AND CP."AddrType" = F."AddrType"
WHERE NOT (F."Cnpj" = '' AND F."Cpf" = '' AND F."Address" <> '')
ORDER BY "Problem" DESC, F."CardCode";

A note on the check digit. For DV1, multiply the first 12 characters by 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2; for DV2, multiply the first 13 by 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2. Take the sum modulo 11: a remainder of 0 or 1 gives 0, otherwise the digit is 11 minus the remainder. With ASCII minus 48, a numeric CNPJ gives exactly the same result as the old rule, which is why one query covers both. I tested the arithmetic against SAP’s example 12ABC34501DE35, the classic test CNPJ 11222333000181 and the CPF 16370927848 from SAP’s help, plus mutated versions of each. I have not run it on a live Brazilian database, so run it on a copy first and compare a few rows by hand.

Two shorter checks finish the master-data sweep before an NF-e go-live:

-- SQL Server: items sold in the last 90 days without an NCM code, and A/R invoice lines without CFOP
SELECT DISTINCT I.ItemCode, I.ItemName, 'Item has no NCM code' AS Problem
FROM INV1 L JOIN OINV H ON H.DocEntry = L.DocEntry JOIN OITM I ON I.ItemCode = L.ItemCode
WHERE H.DocDate >= DATEADD(DAY, -90, GETDATE()) AND ISNULL(I.NCMCode, -1) = -1 AND I.ItemType = 'I'
UNION ALL
SELECT DISTINCT CAST(H.DocNum AS NVARCHAR(20)), L.ItemCode, 'Invoice line without CFOP'
FROM INV1 L JOIN OINV H ON H.DocEntry = L.DocEntry
WHERE H.DocDate >= DATEADD(DAY, -90, GETDATE()) AND ISNULL(L.CFOPCode, '') = '';

On HANA, replace DATEADD(DAY, -90, GETDATE()) with ADD_DAYS(CURRENT_DATE, -90), ISNULL with IFNULL, CAST(... AS NVARCHAR(20)) with TO_NVARCHAR(...), and quote every table and column name.

What should you ask before a SAP Business One project in Brazil?

These questions separate a smooth Brazilian rollout from a painful one, and none of them needs a Brazilian to answer the first round:

• Which NF-e add-on, and which NT version does its current build support? Ask for the version that handles Nota Técnica 2025.002-RTC and the alphanumeric CNPJ, and whether it also issues NFS-e (service invoices go through the national NFS-e standard or the municipality) and CT-e if you run your own transport.
• Who owns the tax code determination rules? The rules in SAP Business One decide every CFOP and CST. They must be built with your contador, documented, and tested against real cases per state before go-live.
• Which SAP Business One version and database? The ECD file is only documented for the SAP HANA version. If you are on SQL Server and plan to move, see what a SQL to HANA move involves first.
• Where do authorisation status and the XML live? Insist on user-defined fields on the documents for access key, protocol and status, so that reports, approvals and integrations can see them without opening the add-on.

If you already run SAP Business One in Brazil, the queries above and a review of your add-on’s handling of alphanumeric CNPJs are a useful one-day check. For the broader picture of how I approach clearance-model e-invoicing, see the e-invoicing hub and the country guides for Ecuador SRI and Guatemala FEL, the two closest to Brazil’s model in my own work. The tables used on this page are documented in the OCRD, OITM and INV1 references. For add-on or integration work on a Brazilian system, see SAP Business One add-on development and e-invoicing integration; a move to HANA is covered under SQL to HANA migration.

Sources

• SAP Help Portal: Localization for Brazil (SAP Business One 10.0)
• SAP Help Portal: Electronic Invoicing (Brazil)
• SAP Help Portal: Nota Fiscal: Brazil
• SAP Help Portal: Sequence for Nota Fiscal - Setup Window: Brazil
• SAP Help Portal: Fiscal IDs: Brazil
• SAP Help Portal: Fields for External Add-On Reading (SAP Note 1715284)
• SAP Help Portal: SPED Fiscal: Brazil
• SAP Help Portal: Generating the ECD File (SPED Contábil)
• SAP Business One SDK: table CRD7, Fiscal IDs for BP Master Data
• Receita Federal: CNPJ Alfanumérico (IN RFB 2.229/2024, schedule, check digit)
• Portal Nacional da NF-e: technical notes and layout (Nota Técnica 2025.002-RTC)

Related services

• SAP Business One development
• E-invoicing integration