Trazer o que você já tem

Ask your accountant for the folder of incoming XML from the last twelve months — it exists and it is the same one they use for bookkeeping. Upload everything at once, review the suppliers tab first (it is the smallest and the most reusable), approve in bulk and only then move on to the products.

Reading the file produces PROPOSALS, and a proposal is not a record: it does not appear in any search, does not enter reports and cannot be used in an entry. When you approve, the record is created through the same path as someone registering by hand, with the same validations. That is why a crooked XML becomes a rejected proposal, and not a crooked supplier inside your database.

Each proposal has a key: the CNPJ for a supplier, the product code at the issuer for a product. Uploading the same folder twice duplicates nothing — the second reading recognizes what was already proposed and creates no new row. Without that, the first load of a year of invoices would generate thousands of duplicates, and cleaning that up afterwards costs more than typing from scratch.

It does not read SPED and does not calculate opening stock or cash balances. SPED is a separate path: the layout changes every year and the meaning of each block depends on the company's tax regime, so reading it halfway would produce a wrong balance that looks like a right number. Spreadsheet mapping remains in the existing import path, on each registration screen.

The SPED reader brings MASTER DATA: participants become supplier proposals and items become product proposals, with the same duplicate key as the XML (document and code), so the same supplier does not come in twice. Balances, tax calculations and credits are left out on purpose: SPED changes layout every calendar year and the meaning of the blocks depends on the tax regime, so a partial reading would produce a wrong opening balance that looks like a right number — the check matches and the number is wrong. Master data is name, document and description: if it comes in crooked, you see it right away. If the file is in a layout this reader does not know, it refuses and says which one it received, instead of trying anyway.

From the XML itself, without interpretation: the supplier comes from the invoice issuer (CNPJ, legal name, state); the product comes from each item (code, description, NCM, unit); the amount payable comes from the invoice total. The reading is deterministic because the XML has a schema — there is no artificial intelligence guessing fields here, and that is on purpose: guessing the wrong CNPJ is worse than not reading the invoice.