80 faturas alemãs, uma única planilha
Como lidar com o processamento de Rechnung em lote sem entrada manual
O gargalo nas contas a pagar alemãs não é extrair dados de uma única Rechnung. Qualquer ferramenta OCR decente consegue extrair um número de fatura e um total de um PDF limpo. O gargalo é o que acontece quando você extrai todas as 80 — e descobre que a Rechnung #12 do eletricista local tem 7% de IVA sobre mão de obra, mas 19% sobre materiais divididos na mesma linha, a Rechnung #37 da Metro aplica um desconto de 4% Skonto escondido no rodapé, e a planilha mesclada que sua ferramenta produziu não tem coluna para informar qual fatura contribuiu com qual linha. Extrair uma Rechnung leva 3 minutos. Verificar e corrigir 80 leva uma tarde inteira.
Quando Chegam 80 Rechnungen — Por Que o Lote Não É Apenas "Único × 80"
Processar uma fatura de cada vez funciona até que não funcione. Para a maioria das empresas alemãs, o ponto de inflexión se situa entre 30 e 50 Eingangsrechnungen por mês — o limiar onde se abre a brecha entre "posso fazer isso na sexta à tarde" e "isso está comendo meu fim de semana". Com 80 faturas, o problema não é a velocidade de entrada de dados por fatura. É que os fluxos de trabalho de fatura única introduzem quatro problemas estruturais que o processamento em lote herda e amplifica:
Deriva de formato. Quando você processa faturas uma a uma e insere manualmente os dados em Lexware ou sevDesk, seu cérebro compensa as diferenças de layout — você vê "Rechnungs-Nr." em uma fatura da Metro e "Rechnungsnummer" em uma da Transgourmet e sabe que são o mesmo campo. Uma extração automática em lote não tem essa intuição, a menos que você tenha ensinado o que procurar — não pela posição do modelo, mas pelo significado semântico. Oito fornecedores, oito layouts e uma saída em lote que os mistura todos em uma única planilha.
Fragmentación do IVA. As Eingangsrechnungen alemãs não usam uniformemente uma única alíquota de IVA. Em um lote de 80 faturas de fornecedores de hospitalidade, aparecem até quatro tratamentos de IVA: padrão 19% (equipamento, limpieza), reduzido 7% (alimentos, livros), §13b reverse charge (trabajos de construcción de subcontratistas) e §19 Kleinunternehmer (sem IVA). Uma única columna "Imposto" que captura um número de cada fatura é inútil — porque esse número significa algo diferente em cada fila, e seu cálculo de Vorsteuerabzug precisa que sejam separados por tipo. Os campos obrigatórios do §14 UStG em cada fatura determinan o que deve ser extraído — mas o processamento em lote adiciona a capa de manter essa extração semanticamente consistente em todas as 80 filas.
Propagación de erros. Quando você insere 80 faturas manualmente, cada uma é uma operação independente — um erro de digitação na Rechnung #44 não se propaga a um erro na #45. Em uma extração em lote, se a IA identifica incorretamente o nome do fornecedor em uma fatura porque a posição do logotipo se deslocou, você não saberá até revisar toda a saída. E se o mapeamento de colunas estiver errado — digamos, a columna Leistungsdatum capturou o Rechnungsdatum em um fornecedor que formatea datas de forma diferente — você precisa verificar cada fila, não apenas a que notou.
Lacunas de rastreabilidade. Uma planilha mesclada de 80 filas precisa dizer de qual arquivo ve veio cada fila. Se você precisa voltar a uma fatura original para verificar uma USt-IdNr ou revisar uma linha de descuento, precisa de um mapeamento confiable de nome de arquivo a fila. Ferramentas de lote que producen un CSV sem columna de documento de origem convierten la auditoría en una búsqueda del tesoro en tu carpeta de Descargas.
Ninguno de estos problemas existe cuando procesas tres faturas. Con 80, los cuatro están activos simultáneamente — y resolverlos es lo que separa un flujo de trabajo de procesamiento en lote de "extracción única, repetida 80 veces".
O Problema do Formato do Fornecedor — Uma Planilha, Oito Layouts Diferentes
Uma fatura da Metro e uma fatura da Transgourmet compartilham a mesma estrutura legal sob o §14 UStG, mas não se parecem em nada. A Metro coloca o Rechnungsnummer no bloco superior direito, a Transgourmet em um cabeçalho de tabela. A Bäckerei local pode enviar uma Rechnung manuscrita onde o bloco de endereço do fornecedor não tem rótulo explícito algum — você o reconhece porque está no canto superior esquerdo e começa com o nome da rua. Este é o argumento central contra a extração em lote baseada em modelos para faturas alemãs: cada novo fornecedor obriga você a criar e manter um novo modelo de extração.
Para colocar isso em perspectiva: um grupo de restaurantes alemão de médio porte pode receber faturas da Metro (atacado de alimentos), Transgourmet (bebidas), um Gemüsehändler local (produtos frescos), vários Getränkelieferanten (distribuidores de bebidas), um serviço de limpeza, uma Wartungsfirma (manutenção de equipamentos) e uma agência de marketing — além de fornecedores ocasionais pontuais. Isso são oito formatos de fatura distintos antes mesmo de considerar as variações dentro da própria Metro (fatura padrão, nota de entrega, Stornorechnung), que usam o mesmo layout da marca, mas reorganizam os campos. Ferramentas baseadas em modelos exigem uma configuração separada para cada variante. Com extração semântica, você define os nomes das colunas uma única vez.
Esta é a diferença entre a abordagem de nomes de colunas e a abordagem de modelos em escala. Extração de Colunas Personalizadas — o mecanismo que o ImageToTable.ai usa — funciona entendendo o significado dos campos, não por coordenadas. Você digita os nomes das colunas desejadas: "Rechnungsnummer", "Lieferant", "Rechnungsdatum", "Leistungsdatum", "Nettobetrag", "USt-Satz", "USt-Betrag", "Bruttobetrag", "USt-IdNr" — e a IA localiza cada valor em cada fatura do lote entendendo o que o rótulo significa, independentemente de onde aparece ou se o texto do rótulo varia ("Rechnungs-Nr." vs "Rechnungsnummer" vs "RNr."). Uma definição de coluna cobre todos os oito layouts de fornecedores em um único upload em lote.
A implicação prática: você envia a pasta inteira do mês de Eingangsrechnungen — 80 PDFs, JPGs e documentos digitalizados de todos os fornecedores — e recebe uma planilha mesclada onde cada linha representa uma Rechnung com as mesmas colunas, independentemente do formato. Sem modelo por fornecedor, sem pré-classificação de formato, sem "as faturas deste fornecedor devem ser enviadas separadamente porque o layout é diferente."
A Divisão da Alíquota de IVA em 80 Notas Fiscais — Por Que uma Única Coluna de "Imposto" Falha
Agora suponha que a extração em lote funcionou — todas as 80 notas fiscais estão na sua planilha com colunas consistentes. O próximo problema é que a coluna USt-Satz contém quatro valores diferentes — 19%, 7%, 0% (ou em branco) e "§13b" — e cada um exige um tratamento contábil diferente. Se você simplesmente SOMAR a coluna USt-Betrag, estará somando IVA regular de 19% que pode ser recuperado como Vorsteuerabzug (sob §15 UStG), IVA reduzido de 7% que também se qualifica para dedução, mas deve ser relatado separadamente (linha 66 da Umsatzsteuervoranmeldung), e valores §13b onde a obrigação de IVA é transferida para o destinatário — o que significa dedução zero e uma obrigação de declaração separada.
A Umsatzsteuervoranmeldung — a declaração mensal ou trimestral de IVA da Alemanha, enviada via ELSTER — exige que os valores de IVA sejam declarados sob códigos fiscais específicos (Kennzahlen):
| Cenário de IVA | Kennzahl ELSTER | O Que Significa em um Lote | O Que Sua Planilha Precisa |
|---|---|---|---|
| Alíquota padrão de 19% | Kennzahl 66 | IVA recuperável — a maior categoria para a maioria das empresas | Linhas onde USt-Satz = 19% → SOMA(USt-Betrag) → vai para Kz 66 |
| Alíquota reduzida de 7% | Kennzahl 66 (subconjunto) | Também recuperável, mas seu Steuerberater pode querer a divisão visível | Linhas onde USt-Satz = 7% → SOMA(USt-Betrag) → subtotal separado, ainda Kz 66 |
| §13b reverse charge | Kennzahl 46+47 | Você autoliquida o IVA e deduz na mesma declaração — saldo zero, mas deve ser declarado | Linhas onde USt-Satz = §13b → sinalizar para atenção do Steuerberater, não somar em Kz 66 |
| §19 Kleinunternehmer | Irrelevante | Sem IVA na nota = sem dedução a reivindicar. Ainda é uma despesa comercial válida. | Linhas onde USt-Satz = em branco/0 — nenhuma entrada de IVA necessária, mas Nettobetrag ainda relevante como Aufwand |
| Kleinbetragsrechnung (§33 UStDV) | Kz 66 (se IVA incluído) | Notas abaixo de €250 brutas — Pflichtangaben simplificados, mas o IVA ainda se aplica | Pode não declarar IVA explicitamente — calcular 19/119 ou 7/107 do Brutto se necessário |
Uma abordagem prática para lidar com isso em uma extração em lote: defina uma coluna inferida — uma coluna em que a IA classifica a nota fiscal com base no conteúdo, em vez de extrair um valor que está explicitamente na página. Por exemplo, uma coluna chamada VAT Type (options: Standard 19%/Reduced 7%/§13b Reverse Charge/Kleinunternehmer §19) instrui a IA a ler cada nota, determinar qual regime de IVA se aplica e gerar o rótulo de categoria correto. Isso fornece uma coluna filtrável — e, a partir dela, você agrupa por tipo de IVA e soma o USt-Betrag de cada grupo separadamente para sua declaração de Vorsteuerabzug. A extração e a classificação acontecem em uma única etapa, não em duas operações separadas.
Isso também é importante para o lado das despesas da sua Buchhaltung. O Nettobetrag em uma nota §13b ainda é uma despesa operacional (Aufwand), mesmo que tenha IVA de entrada zero — se você o excluir do resumo de custos porque "sem imposto = irrelevante", estará subnotificando despesas. A extração em lote precisa capturar o quadro financeiro completo, não apenas a parcela relevante para o IVA.
Da Extração em Lote ao Seu Steuerberater — Pronto para DATEV em um Único Export
Extrair 80 notas fiscais para uma planilha resolve o problema de entrada de dados. Isso não resolve automaticamente o problema da transferência — a etapa em que essa planilha precisa se tornar algo que seu Steuerberater possa importar para o DATEV sem redigitar cada linha. Os consultores fiscais alemães usam as plataformas Kanzlei-Rechnungswesen e Unternehmen Online da DATEV, que importam dados por meio de dois mecanismos principais de lote:
Importação CSV (Formato DATEV) para Kanzlei-Rechnungswesen — um CSV de colunas fixas com ordenação específica de campos: Belegdatum, Buchungstext, Gegenkonto, Betrag, indicador Soll/Haben e, opcionalmente, o Buchungsschlüssel (chave de lançamento) e a Kontierung (número de conta conforme SKR03 ou SKR04). O arquivo deve usar ponto e vírgula como delimitadores, codificação ISO-8859-1 e formato de data DD.MM.YYYY — exportações CSV de ferramentas em inglês que usam vírgulas e MM/DD/YYYY por padrão falharão silenciosamente.
Importação XML (dxso-Jobs) para DATEV Unternehmen Online — um envio de job em lote usando o esquema XML proprietário da DATEV. O mecanismo dxso (DATA XML Send Online) aceita dados de notas fiscais estruturados como documentos XML, validados contra os esquemas XSD da DATEV. XML é obrigatório para Unternehmen Online; CSV é para o aplicativo de desktop Rechnungswesen — e seu Steuerberater pode usar um ou ambos, dependendo do fluxo de trabalho.
O ponto-chave: suas colunas de extração devem espelhar as colunas de importação que seu sistema de destino espera. Se seu Steuerberater precisar do Belegdatum no formato DD.MM.YYYY, defina sua coluna de extração como "Belegdatum" — não "Invoice Date". Se eles lançarem despesas na conta 4930 (SKR03: Sonstige Kosten), inclua uma coluna chamada "SKR03 Konto" com o código apropriado. Isso elimina a etapa intermediária de reformatar uma saída de extração genérica para corresponder aos esquemas do software contábil. A extração é o arquivo de importação.
Para um lote de 80 notas fiscais destinadas ao DATEV, o conjunto de colunas pode ser assim:
- Belegdatum — DD.MM.YYYY
- Buchungstext — combinação de Lieferant + Rechnungsnummer
- Gegenkonto — o número Kreditor do fornecedor (série 70000 no SKR04)
- Betrag — Bruttobetrag (valor bruto)
- Soll/Haben — "S" para débito (despesa), "H" para crédito
- SKR03 Konto — a conta de despesa (ex.: 4930 para custos diversos, 3400 para Waren)
- USt-Satz — 19 ou 7 ou 0
- Vorsteuerbetrag — o valor de IVA recuperável
O Lexware Office e o sevDesk usam seus próprios modelos de CSV, mas o princípio é o mesmo: defina as colunas de extração para corresponder ao esquema de importação, exporte como CSV e importe diretamente. A proposta de valor do processamento em lote — 80 notas fiscais em minutos — só é totalmente alcançada se a saída não exigir mais uma hora de reformatação de planilha.
O Fluxo de Trabalho — Como Processar 80 Eingangsrechnungen de Uma Vez
Com os desafios estruturais mapeados — diversidade de formatos, fragmentação de IVA e compatibilidade com DATEV — aqui está o fluxo de trabalho em lote de ponta a ponta, de uma pasta com 80 Rechnungen a uma planilha pronta para o Steuerberater:
VAT Type (options: Standard 19%/Reduced 7%/§13b Reverse Charge/Kleinunternehmer §19) para classificar automaticamente cada fatura. Se for exportar para DATEV, alinhe os nomes das colunas com o esquema de importação (Belegdatum em vez de "Date", Bruttobetrag em vez de "Total"). Esta definição de colunas é reutilizada em cada lote — você a define uma vez, não por lote.Os arquivos são processados com segurança e não são armazenados. Envie várias Rechnungen para ver a extração em lote em ação.
Especificamente na etapa de verificação: os itens de maior risco em um lote não são os que parecem errados — são os que parecem certos, mas contêm um campo que foi sistematicamente lido incorretamente devido a uma peculiaridade de formatação específica do fornecedor. Uma fatura da Metro que alinha seu Nettobetrag de forma diferente das outras 79 faturas não mostrará erro — a célula conterá um número, e o número parecerá plausível. A verificação que detecta isso é a conferência do top 10 por Bruttobetrag: abra a fatura original da Metro, compare o total bruto com o total bruto extraído. Se corresponder, a extração provavelmente está correta. Se não corresponder, há uma peculiaridade de formatação a investigar.
Arquivamento em Lote em Conformidade com a GoBD — Não Arquivar o Excel, Arquivar os Originais
O processamento em lote cria um atalho tentador: extrair 80 faturas em uma planilha limpa, arquivar a planilha e excluir os originais bagunçados. Este é o erro de conformidade com a GoBD mais comum no processamento automatizado de faturas — e ele falha nos requisitos de auditoria em vários níveis.
A GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern), revisada em julho de 2025 para se alinhar ao mandato de faturamento eletrônico da Alemanha, exige que documentos fiscalmente relevantes sejam preservados em seu formato original recebido, não em uma versão derivada ou transformada. Especificamente:
- Faturas eletrônicas estruturadas (XML XRechnung, PDF híbrido ZUGFeRD): O XML é o registro fiscal autoritativo. Se a fatura chegou como um PDF ZUGFeRD, o arquivo PDF/A-3 inteiro (incluindo o XML incorporado) deve ser arquivado como uma unidade. A emenda de julho de 2025 confirmou que uma cópia separada em PDF legível por humanos não é necessária, a menos que contenha informações adicionais relevantes para fins fiscais não presentes no XML — como notas de pagamento manuscritas na camada visual.
- PDFs simples e documentos digitalizados: O arquivo original deve ser retido em forma inalterada por 10 anos, conforme §147 AO. Uma linha extraída no Excel é uma cópia de trabalho — não é um substituto de arquivo.
- Faturas em papel fotografadas: A foto digital torna-se o registro. O princípio da GoBD de Unveränderbarkeit (imutabilidade) significa que o arquivo de foto deve ser armazenado de forma a impedir modificações subsequentes — com timestamp, hash ou armazenado em um sistema com bloqueio de revisão.
A saída da extração — sua planilha Excel de 80 linhas — é um documento operacional, não um documento de arquivo. Ela serve para sua Buchhaltung do dia a dia, cálculo de Vorsteuerabzug e importação DATEV. Para uma Betriebsprüfung (auditoria fiscal), o auditor solicitará os arquivos de fatura originais, não sua planilha de extração. A extração só precisa permitir a rastreabilidade de volta aos originais — o que significa que a planilha deve incluir uma coluna que identifique o arquivo de origem para cada linha (nome do arquivo ou número de referência). Sem essa coluna de rastreabilidade, uma extração em lote de 80 faturas cria 80 linhas de dados que não podem ser verificadas em relação às suas fontes — uma falha de conformidade com a GoBD, independentemente da precisão da extração.
O fluxo de trabalho prático de arquivamento em lote: mantenha os arquivos originais em uma pasta datada (ex.: /Eingangsrechnungen/2026-05/), nomeie-os de forma consistente (2026-05-03_Metro_INV-48291.pdf) e garanta que sua saída de extração preserve o nome do arquivo como uma coluna. Se seu Steuerberater usa DATEV Unternehmen Online, os arquivos de fatura originais podem ser anexados às entradas contábeis correspondentes por meio do recurso Belegverwaltung (gerenciamento de documentos) — fechando o ciclo de rastreabilidade da planilha de volta ao documento de origem e ao trilho de auditoria do DATEV.
O mandato de faturamento eletrônico em fases da Alemanha — recebimento obrigatório desde janeiro de 2025, envio obrigatório para empresas com faturamento acima de €800 mil a partir de 2027, envio universal a partir de 2028 — está gradualmente reduzindo o problema dos "originais bagunçados". À medida que os fornecedores migram para ZUGFeRD e XRechnung, a camada XML incorporada entrega dados estruturados sem OCR. Mas durante o período de transição, seu pipeline em lote lidará com uma mistura: alguns PDFs ZUGFeRD, alguns PDFs simples, algumas Rechnungen digitalizadas de fornecedores que não mudarão até 2028. O fluxo de trabalho de extração precisa lidar com os três, e o fluxo de trabalho de arquivamento precisa preservar os três em seus respectivos formatos originais.
Perguntas Frequentes
Posso realmente processar notas fiscais da Metro, Transgourmet e de um Handwerker local no mesmo lote?
Sim. Como a extração é orientada pela semântica dos nomes das colunas — a IA lê o significado do campo, não a posição — a mesma definição de coluna (Rechnungsnummer, Lieferant, Bruttobetrag, etc.) funciona em diferentes layouts de fornecedores. Você não precisa de um modelo separado por fornecedor. A única ressalva: se dois fornecedores usam um rótulo idêntico para coisas diferentes (ex.: ambos têm um campo "Datum", mas um significa data da nota e o outro data de entrega), defina suas colunas com precisão — "Rechnungsdatum" e "Lieferdatum" em vez de um "Date" genérico.
Como lidar com a divisão do IVA quando algumas notas têm itens com 19% e 7%?
Para notas com alíquotas de IVA mistas, defina pares de colunas separados: "Nettobetrag 19%," "USt-Betrag 19%," "Nettobetrag 7%," "USt-Betrag 7%." A IA extrai cada grupo de alíquota independentemente da nota. Se uma nota tiver apenas itens com 19%, as colunas de 7% ficarão vazias — e vice-versa. Na saída do lote, você pode então SOMAR a coluna USt-Betrag 19% e a coluna USt-Betrag 7% separadamente para seu cálculo de Vorsteuerabzug. Para notas complexas onde a divisão não é clara — uma nota de restaurante que mistura comida e álcool (19%) na mesma linha — adicione uma coluna calculada para recalcular a divisão correta a partir das quantidades dos itens e preços unitários, e confira com o detalhamento de IVA declarado na nota.
O que acontece se uma nota no lote tiver um campo ausente — isso quebra o lote inteiro?
Não. A IA processa cada nota independentemente dentro do lote. Se a Rechnung nº 23 estiver sem o campo USt-IdNr (comum em Kleinbetragsrechnungen abaixo de €250, que não o exigem), essa célula ficará vazia para aquela linha — todas as outras linhas não são afetadas. A etapa de verificação no fluxo de trabalho foi projetada para capturar isso: classifique pela coluna obrigatória e procure por espaços em branco. Você pode então preencher o valor ausente manualmente (se souber o USt-IdNr do fornecedor de uma nota anterior), aceitar o espaço em branco se for legítimo (Kleinbetragsrechnung), ou sinalizá-lo para acompanhamento com o fornecedor se for um campo obrigatório em uma nota completa.
Posso exportar diretamente para o formato CSV DATEV a partir da extração em lote?
Você pode exportar para Excel (XLSX) ou CSV e, em seguida, mapear as colunas para o formato CSV DATEV que seu Steuerberater exige. A saída da extração em lote é uma planilha estruturada — as colunas que você definiu tornam-se as colunas do Excel. Se você nomear suas colunas para corresponder aos campos de importação DATEV (Belegdatum, Buchungstext, Gegenkonto, Betrag, etc.), a exportação já estará na estrutura correta — talvez seja necessário reorganizar a ordem das colunas e garantir que o delimitador e os formatos de data correspondam às especificações exatas do DATEV (ponto e vírgula, DD.MM.YYYY, codificação ISO-8859-1). A ferramenta não produz CSV no formato DATEV nativamente, mas os dados extraídos mapeiam diretamente para ele com reformatação mínima.
O processamento em lote funciona com notas fiscais XML ZUGFeRD e notas fiscais em papel escaneadas misturadas no mesmo upload?
Sim, o lote pode conter uma mistura de PDFs ZUGFeRD, PDFs simples, digitalizações JPG e fotos — a IA lê a camada visual de cada documento. Para notas fiscais ZUGFeRD, ela lê a renderização visível do PDF; não analisa o XML incorporado. Na prática, isso significa que a precisão da extração em uma nota fiscal ZUGFeRD é determinada pela qualidade do layout visual, não pela presença do XML — o mesmo que um PDF simples. Para arquivos XML XRechnung puros (sem PDF visual), a ferramenta não foi projetada para processá-los — use um conversor de XML para CSV para esses casos, ou peça ao fornecedor que também forneça a versão em PDF legível.
Como lidar com o Skonto (desconto por pagamento antecipado) na extração em lote?
O Skonto — normalmente um desconto de 2-3% para pagamento em 7-14 dias — geralmente é indicado em uma nota em vez de um campo dedicado (ex.: "2% Skonto bei Zahlung innerhalb 10 Tagen"). Se você precisar rastreá-lo, defina uma coluna chamada "Skonto (%)" — a IA extrairá a porcentagem se ela estiver indicada na nota fiscal. Para o Nettobetrag, normalmente você quer o valor total antes do Skonto (Bemessungsgrundlage), não o valor com desconto, porque o IVA é calculado sobre o valor total conforme §10 UStG. Se a nota fiscal indicar o total com desconto, use uma coluna calculada para recalcular o Nettobetrag antes do Skonto para fins de Vorsteuerabzug, pois o fisco determina o IVA sobre o valor bruto antes do desconto.
Colocando Seu Fluxo de Trabalho em Lote para Notas Fiscais Alemãs em Funcionamento
O processamento em lote de Eingangsrechnungen alemãs fica em uma interseção específica: é o ponto em que o número de notas fiscais cruza de "entrada manual é chata, mas administrável" para "entrada manual é um sumidouro estrutural de tempo". Para a maioria das PMEs alemãs, essa linha fica entre 40 e 60 notas fiscais por mês. Abaixo disso, o atrito vem do fluxo de trabalho — abrir o DATEV, digitar campos, salvar. Acima disso, o atrito é sistêmico: diversidade de formatos, fragmentação de IVA e lacunas de rastreabilidade que sobrevivem a qualquer fluxo de trabalho de nota fiscal individual.
A abordagem de processamento em lote descrita aqui — extração baseada em nomes de colunas que funciona em vários formatos de fornecedores, coluna inferida para classificação automática de IVA e esquemas de exportação alinhados ao DATEV — aborda os problemas sistêmicos, não apenas a velocidade por nota fiscal. O ganho de eficiência de 18x (3 minutos por nota fiscal manualmente vs 5-10 segundos com extração) é o número de destaque. Mas a mudança operacional maior é esta: todas as Eingangsrechnungen do mês se tornam uma única operação. Não 80 operações feitas rapidamente — uma operação feita uma vez. A diferença é a diferença entre "fiquei mais rápido na entrada de dados" e "a entrada de dados deixou de fazer parte do meu fechamento mensal".
Envie várias Rechnungen — teste grátis, sem necessidade de conta para as primeiras 50 páginas.