Cada encomenda numa única cronologia, da receção à fatura paga.
Os processos order to cash, procure to pay e do pedido de serviço à fatura atravessam ERP, CRM, comércio eletrónico, armazém, transporte e sistemas financeiros. Ligamo-los com APIs e eventos documentados, damos a cada encomenda um único estado em todos esses sistemas e enviamos cada exceção a um agente que prepara uma resolução para uma pessoa aprovar.
Para organizações que vendem, compram e faturam em Portugal e noutros Estados-Membros da UE, cada um com os seus sistemas, transportadores e regras de faturação eletrónica.
Uma encomenda, uma nota de encomenda a fornecedor ou um pedido de serviço é registado uma única vez no seu sistema de referência e distribuído aos outros sistemas através de APIs e eventos documentados. Os eventos de estado constroem uma cronologia por encomenda. Quando um passo falha ou sai da tolerância, um agente reúne o contexto e propõe uma resolução, que uma pessoa aprova antes de ser executada no sistema de referência. As faturas são trocadas e conciliadas como faturas eletrónicas estruturadas, e os responsáveis pelos processos reveem o fluxo e o estado das interfaces.
Antes e depois
O que muda nas operações do dia a dia
Hoje
Com o sistema
Hoje
Hoje: Introduzido de novo a cada passagem
Uma encomenda feita na loja online ou pela equipa comercial é escrita outra vez no ERP, e os dados de entrega e de faturação são copiados à mão para os sistemas de armazém, de transporte e financeiros.
Com o sistema
Com o sistema: Introduzido uma vez, usado em todo o lado
Cada encomenda, entrega e fatura é criada no sistema que é responsável por ela e publicada como evento. Os outros sistemas subscrevem esse evento em vez de o voltarem a escrever.
Hoje
Hoje: O estado de ontem
Com interfaces noturnas em lote, o apoio ao cliente, o planeamento e as finanças veem cada um um estado diferente e desatualizado da mesma encomenda. Um cliente que pergunta onde está uma entrega fica à espera de que lhe liguem de volta.
Com o sistema
Com o sistema: Um único estado atual
Cada encomenda ou pedido tem uma cronologia construída a partir dos eventos de todos os sistemas por onde passa. O apoio ao cliente, o planeamento e as finanças olham para os mesmos factos, e o mesmo pode fazer um assistente de atendimento que responde a perguntas sobre o estado.
Hoje
Hoje: Exceções tratadas por e-mail
Faltas de stock, diferenças de preço, entregas falhadas e faturas eletrónicas rejeitadas são resolvidas por e-mail e em folhas de cálculo, e ninguém sabe dizer depois quem decidiu o quê.
Com o sistema
Com o sistema: As exceções chegam com uma proposta
Um agente reúne os dados por trás de cada exceção e propõe uma resolução. Uma pessoa aprova, edita ou rejeita a proposta num único painel de exceções, e a decisão fica registada.
Hoje
Hoje: Dados mestre que não coincidem
O mesmo cliente, fornecedor, produto ou preço existe em vários sistemas com valores diferentes, e ninguém é responsável por saber qual está certo.
Com o sistema
Com o sistema: Um responsável por cada objeto de dados
Clientes, fornecedores, produtos e preços têm cada um um sistema de referência acordado e um responsável identificado. Os duplicados e os conflitos são comunicados a esse responsável, e não corrigidos em silêncio mais à frente.
Hoje
Hoje: Cada mudança acrescenta uma interface
Um novo canal de venda, um marketplace ou uma nova empresa do grupo significam mais uma ligação ponto a ponto. As obrigações nacionais de faturação eletrónica acrescentam ainda um formato estruturado e uma rede a cada processo.
Com o sistema
Com o sistema: As novas ligações reutilizam os mesmos contratos
Um novo canal, uma nova empresa ou uma nova rede de faturação eletrónica ligam-se uma única vez a APIs e eventos documentados, em vez de a cada sistema separadamente.
Fluxo de trabalho
Como funciona o fluxo de trabalho
Quando os dados estão limpos, o percurso principal não precisa de trabalho manual. Quando uma encomenda, uma entrega ou uma fatura se desvia, o ciclo de exceção leva-a a uma pessoa com a evidência e uma proposta, e a correção aprovada volta a passar pela mesma camada de integração.
Fluxo de trabalho ilustrativo
7 passos · 1 ponto de controlo humano
Legenda
Sistema
Agente de IA
Pessoa
Ponto de controlo humano
Via de exceção
Operações integradas: fluxo ilustrativo com ciclo de exceção
Ler o diagrama em texto
O percurso principal vai do registo de um evento de negócio uma única vez no seu sistema de referência, passando pela sua distribuição aos outros sistemas por APIs e eventos e pela construção de uma cronologia por encomenda, até à faturação, conciliação e liquidação. Termina com os responsáveis pelos processos a rever o fluxo e a corrigir as causas das exceções.
Quando um passo falha, se atrasa ou sai da tolerância, a exceção sai do percurso principal depois do passo da cronologia. Um agente reúne o contexto e propõe uma resolução, e uma pessoa aprova, edita ou rejeita a proposta. A ação aprovada é executada no sistema de referência e regressa ao passo de distribuição como um novo evento.
O passo de aprovação é o ponto de controlo humano: nenhum movimento financeiro, alteração de preço ou de limite de crédito, nem compromisso com um cliente, é feito sem uma pessoa.
01
Passo 1: Registar o evento uma vezSistema
Uma encomenda de cliente vinda da loja online, de um marketplace, de EDI ou da equipa comercial, uma nota de encomenda a fornecedor ou um pedido de serviço é criado no sistema responsável por ele. Esse sistema publica um evento de negócio num envelope CloudEvents, descrito num contrato AsyncAPI. As encomendas em papel e em PDF e as faturas de fornecedores passam primeiro pelo processamento inteligente de documentos.
02
Passo 2: Distribuir por APIs e eventosSistema
A camada de integração entrega o evento aos sistemas de armazém, de transporte, financeiros e de CRM através das respetivas APIs documentadas (OpenAPI). Os consumidores são idempotentes, para que uma mensagem repetida nunca crie uma segunda expedição ou fatura, e as mensagens que não podem ser entregues aguardam numa fila de erros até serem reenviadas.
03
Passo 3: Uma cronologia por encomendaSistema
Os eventos de estado de todos os sistemas (confirmada, preparada, expedida, entregue, faturada, paga) são correlacionados pela referência de negócio numa única cronologia. Regras de marcos e de tolerância geram uma exceção quando um passo falha, se atrasa ou não coincide: uma falta de stock, um preço fora da tolerância acordada, uma entrega falhada, uma fatura eletrónica rejeitada.
04
Passo 4: Reunir o contexto e proporAgente de IA
Para cada exceção, um agente lê o que precisa nos sistemas envolvidos: a encomenda, os níveis de stock, o acordo de preços, o estado do transportador e as condições do cliente. Propõe uma resolução com o seu raciocínio e os dados que usou, como um artigo alternativo, um preço corrigido, uma nova data de entrega ou uma fatura corrigida.
Via de exceção: Passo falhado ou fora da tolerância
05
Passo 5: Aprovar dentro dos limitesPessoa
Um trabalhador do apoio ao cliente, da logística ou das finanças vê a exceção, a evidência e a proposta no painel de exceções, e aprova, edita ou rejeita. A ação aprovada é executada através da API do sistema de referência, que publica a alteração como um novo evento.
Via de exceção: Passo falhado ou fora da tolerância· Regressa ao passo 2
Ponto de controlo humano
Os agentes nunca lançam movimentos financeiros, alteram preços ou limites de crédito, nem assumem compromissos com clientes sem aprovação. Os limites por tipo de ação definem quem aprova, e cada proposta e cada decisão ficam registadas.
06
Passo 6: Faturar, conciliar e liquidarSistema
As faturas emitidas saem do ERP como faturas eletrónicas estruturadas (Peppol BIS Billing 3.0, EN 16931, ou CIUS-PT nas faturas a entidades públicas portuguesas) através de um ponto de acesso. As faturas de fornecedores recebidas são conciliadas com as notas de encomenda e as receções de mercadoria, e o estado do pagamento vindo do banco ou do prestador de pagamentos fecha a cronologia.
07
Passo 7: Rever o fluxo e corrigir as causasPessoa
Os responsáveis pelos processos e a equipa de integração reveem, com uma cadência fixa, as exceções por motivo, as falhas de interface e os conflitos de dados mestre. Corrigem a causa onde ela está, num registo de dados mestre, numa regra de tolerância ou num mapeamento, em vez de voltarem a resolver a mesma exceção.
Componentes
O que construiríamos
01
Camada de integração orientada por eventos
APIs e eventos definidos primeiro por contrato entre ERP, CRM, comércio eletrónico, armazém, transporte e finanças, especificados em OpenAPI e AsyncAPI com envelopes CloudEvents, na sua plataforma de integração atual ou construídos de raiz na cloud.
Um sistema de referência e um responsável acordados por objeto de dados, regras de correspondência para clientes, fornecedores e produtos, e relatórios de duplicados e conflitos para as pessoas responsáveis por eles.
Um serviço que correlaciona os eventos numa cronologia por encomenda ou pedido, aplica regras de marcos e de tolerância e mostra o fluxo e as exceções aos responsáveis pelos processos.
Uma fila de exceções que mostra o contexto reunido e a proposta do agente, com as ações aprovar, editar e rejeitar e limites de aprovação aplicados por tipo de ação no ponto onde a ação é executada.
Faturas Peppol BIS Billing 3.0 e EN 16931 em UBL, enviadas e recebidas através de um ponto de acesso e validadas antes do envio, com as faturas rejeitadas encaminhadas para o painel de exceções.
Monitorização e alertas por interface, manuais de operação para a equipa de operações e reenvio controlado das mensagens falhadas, implementados com infraestrutura como código no seu ambiente de cloud.
Pedidos de serviço e relatórios de intervenção no terreno
Seguimento e eventos de entrega dos transportadores
Faturas eletrónicas Peppol e respostas de estado
Extratos bancários e avisos de pagamento
Núcleo da solução
Operações integradas
Sistemas com que trabalha
SAP S/4HANA, vendas, compras e finançasPlataformaSAP
Salesforce Sales, Service e Commerce CloudPlataformaSalesforce
Odoo, vendas, inventário, compras e contabilidadePlataformaOdoo
Plataformas de comércio eletrónico, marketplaces e APIs de transportadores
Sistemas de gestão de armazém e de transporte
Ponto de acesso Peppol, bancos e prestadores de pagamentos
Gestão de informação de produto e plataforma de dados
Controlos
Controlos previstos desde o desenho
Limites de acesso
Cada integração e o agente funcionam com a sua própria identidade de serviço em cada sistema, limitada às operações de API de que precisam. O agente pode ler em vários sistemas para reunir contexto, mas só pode escrever através de uma lista curta de ações aprovadas, executadas pela API do sistema de referência e nunca por acesso direto à base de dados.
Revisão humana
Os limites de aprovação são definidos por tipo de ação com o responsável pelo processo: o que o agente só pode propor, o que um membro da equipa aprova e o que precisa de um segundo aprovador. Os movimentos financeiros, as alterações de preços e de limites de crédito e os compromissos com clientes aguardam sempre uma pessoa. Ações de baixo impacto e reversíveis, como reenviar uma mensagem falhada, podem correr sem aprovação se o responsável concordar.
Auditabilidade
Cada evento, proposta, aprovação, rejeição e ação executada fica registado com a referência da encomenda ou do pedido, com os dados que o agente usou, a versão do modelo e do prompt e quem aprovou. Uma fatura contestada ou uma reclamação de um cliente pode ser seguida passo a passo.
Proteção de dados
Os dados de contacto de clientes e fornecedores só seguem para os sistemas que precisam deles. A cronologia guarda referências de negócio e estados, e não registos completos, e os registos seguem o prazo de conservação que definir. O tratamento fica na região acordada.
Transparência da IA
As propostas do agente aparecem assinaladas como tal no painel de exceções, com a evidência e o raciocínio ao lado. Os sistemas de referência continuam a fazer fé: a cronologia mostra o que eles reportam e nunca se lhes sobrepõe.
Indicadores
O que mediríamos
Acordamos estes indicadores consigo na fase de descoberta e retiramos a linha de base dos registos atuais dos seus sistemas e interfaces antes de qualquer alteração.
O que mediríamos
Indicador
Porque é importante
Como o mediríamos
01Tempo de ciclo da encomenda
Porque é importanteO indicador que os clientes notam primeiro, e o que mostra onde as encomendas ficam à espera.
Como o mediríamosTempo entre a receção da encomenda e a entrega e o pagamento, por canal e por empresa, a partir dos eventos da cronologia.
02Encomendas sem intervenção manual
Porque é importanteMostra que parte do fluxo corre com dados limpos e regras acordadas.
Como o mediríamosPercentagem de encomendas e pedidos que chegam à liquidação sem qualquer passo manual nem exceção, a partir da cronologia.
03Exceções por motivo e tempo de resolução
Porque é importanteIndica que causas corrigir primeiro e se o painel de exceções acompanha o volume.
Como o mediríamosVolume de exceções por código de motivo, e tempo entre a deteção e a resolução executada, a partir dos registos do painel de exceções.
04Taxa de rejeição de faturas eletrónicas
Porque é importanteAs faturas rejeitadas atrasam o pagamento e costumam apontar para erros de dados mestre ou de mapeamento.
Como o mediríamosPercentagem de faturas eletrónicas enviadas e recebidas que foram rejeitadas, por motivo, a partir das respostas do ponto de acesso.
05Falhas de interface e tempo de recuperação
Porque é importanteMostra se a camada de integração é fiável e se as falhas são detetadas e corrigidas depressa.
Como o mediríamosMensagens falhadas por interface, e tempo entre a falha e o reenvio bem-sucedido, a partir da monitorização da integração.
06Duplicados e conflitos nos dados mestre
Porque é importanteA maioria das exceções tem origem em dados que diferem entre sistemas.
Como o mediríamosDuplicados e valores em conflito em aberto por objeto de dados e por sistema, a partir dos relatórios de correspondência.
Não fixamos metas antes de existir uma linha de base.
Implementação
Como o poríamos em produção
Fase 01
Descoberta e mapa do processo
Um processo, como o order to cash de um canal de venda, e um tipo de exceção. Mapeamos os sistemas, as interfaces, os responsáveis pelos dados e a forma como as exceções são tratadas hoje.
Critérios de saída
Processo, sistemas e responsáveis pelos dados mapeados
Primeiro tipo de exceção e limites de aprovação acordados
Linha de base retirada dos registos atuais
Fase 02
Integração e cronologia
APIs e eventos documentados para os sistemas abrangidos, e a cronologia a funcionar ao lado das interfaces existentes, sem as alterar.
Critérios de saída
Contratos de eventos publicados e versionados
A cronologia coincide com os sistemas de referência numa amostra de encomendas
Reenvio e manuais de operação testados
Fase 03
Piloto do painel de exceções
O agente propõe resoluções para o tipo de exceção escolhido e as pessoas aprovam todas as propostas. Comparamos as propostas com o que as equipas teriam feito.
Critérios de saída
A qualidade das propostas cumpre os critérios acordados
Limites e aprovadores definidos por tipo de ação
Trilho de auditoria revisto pelas finanças e pelo controlo interno
Fase 04
Alargar e desativar
Mais tipos de exceção, canais, empresas e processos, como o procure to pay, todos sobre os mesmos contratos. As antigas interfaces ponto a ponto são desligadas uma a uma.
Critérios de saída
Cada novo fluxo sobre os mesmos contratos e a mesma monitorização
Encomendas por medida e de peças de substituição, do ERP ao armazém e aos transportadores, com as confirmações e as faturas eletrónicas dos fornecedores conciliadas com as notas de encomenda.
Pedidos de ligação e de intervenção num serviço de águas, acompanhados desde a ordem de trabalho até à visita no terreno e à fatura, e materiais comprados ao abrigo de contratos de fornecimento.
Da compra ao pagamento com faturas eletrónicas estruturadas (CIUS-PT) recebidas pelas entidades públicas, conciliadas com as encomendas e as receções antes do pagamento.
Exemplo ilustrativo
Um exportador de vinho com clientes em vários países
Situação
Um exportador de vinho vende a distribuidores em Portugal e em vários mercados da UE, por uma loja online, por um marketplace e pela equipa comercial, a partir de um armazém próprio. As encomendas são escritas outra vez no ERP, os transportadores comunicam problemas de entrega por e-mail e cada mercado pede as faturas à sua maneira.
Sistema
Encomendas, stock, expedições e faturas circulam como eventos entre a loja online, o ERP, o sistema de armazém e os transportadores, e cada encomenda tem uma cronologia única. As faturas saem como faturas eletrónicas estruturadas por um único ponto de acesso, na rede e no formato que cada cliente ou mercado exige.
Controlo humano
As faltas de stock e as entregas falhadas chegam a um único painel de exceções, onde um agente propõe uma colheita alternativa ou uma nova data de entrega. O apoio ao cliente aprova cada proposta; as alterações de preço e as notas de crédito precisam da aprovação das finanças.
O que mediríamos
Percentagem de encomendas sem intervenção manual por mercado e por canal, exceções por motivo e tempo de resolução, e taxa de rejeição de faturas eletrónicas por mercado.
Portugal
Um processo, vários países e obrigações
As empresas portuguesas que exportam para Espanha e para o resto da UE correm muitas vezes os mesmos processos order to cash e procure to pay em instâncias de ERP, transportadores e bancos diferentes. Desenhamos uma única camada de integração com o formato e a rede de cada país por trás dos mesmos eventos, para que uma nova obrigação signifique um novo conector, e não um novo processo.
Nos contratos públicos em Portugal, as grandes empresas emitem faturas eletrónicas desde 1 de janeiro de 2021, e as PME e as microempresas a partir de 1 de janeiro de 2027; um PDF enviado por e-mail não é uma fatura eletrónica. A eSPap emite os requisitos técnicos e funcionais, e o formato é o CIUS-PT, conforme com a norma europeia EN 16931. Na UE, o pacote IVA na era digital (ViDA) torna a faturação eletrónica estruturada a regra nas operações B2B intra-UE a partir de 1 de julho de 2030.
O Regulamento dos Dados, aplicável desde 12 de setembro de 2025, estabelece regras para a mudança entre serviços de tratamento de dados, por isso mantemos portáveis os contratos de eventos e as exportações de dados. Os agentes do painel de exceções são desenhados a pensar no Regulamento da IA, e as integrações incluem acessos registados e componentes documentados para os clientes que têm de demonstrar a segurança da cadeia de abastecimento ao abrigo do Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025).
Não. O seu ERP, o seu CRM, a sua loja online e o seu sistema de armazém fazem cada um o seu trabalho. Integramos à volta desses sistemas de referência, acordamos que sistema é responsável por que dados e damos ao processo uma única cronologia entre eles. Quando um sistema antigo de encomendas ou um ERP bloqueia a mudança, a modernização de sistemas legados coloca-o primeiro por trás de APIs.
02Substituem o nosso middleware de integração?
Não, se ele cumprir a sua função. Construímos sobre a plataforma de integração ou o message broker que já utiliza, e acrescentamos contratos, monitorização e reenvio onde faltarem. Onde não existe nenhum, construímos de raiz na cloud. Saiba mais sobre o nosso trabalho de integração.
03Os agentes podem agir sozinhos?
Só dentro dos limites que acordar por tipo de ação, e só em ações de baixo impacto que possam ser revertidas, como reenviar uma mensagem falhada. Os movimentos financeiros, os preços, os limites de crédito e os compromissos com clientes precisam sempre de uma pessoa. Leia onde os agentes de IA precisam de aprovação humana.
04Como encaixam as obrigações de faturação eletrónica?
Em Portugal, os fornecedores de entidades públicas emitem faturas eletrónicas nos contratos públicos (artigo 299.º-B do Código dos Contratos Públicos); as PME e as microempresas passam a fazê-lo a partir de 1 de janeiro de 2027, segundo os requisitos da eSPap e no formato CIUS-PT. Noutros Estados-Membros, as obrigações nacionais chegam em datas diferentes, e o pacote IVA na era digital (ViDA) torna a faturação eletrónica estruturada a regra nas operações B2B intra-UE a partir de 1 de julho de 2030. Tratamos a fatura eletrónica como mais um evento do processo: emitida a partir do ERP, enviada por um ponto de acesso e tratada no painel de exceções quando é rejeitada. Consulte o nosso guia sobre a faturação eletrónica e a Peppol.
05Como evitam mais uma rede frágil de ligações ponto a ponto?
Os sistemas publicam e consomem eventos e APIs documentados através de uma única camada, e não por ligações diretas entre si. Os contratos são versionados, os consumidores são idempotentes, as mensagens falhadas podem ser reenviadas e cada fluxo tem um responsável identificado. Um novo canal subscreve os eventos existentes em vez de acrescentar uma ligação a cada sistema.
06Como é um primeiro âmbito?
Um processo e um tipo de exceção, por exemplo o order to cash de um canal de venda com as faltas de stock como primeira exceção. Serve para provar os eventos, a cronologia e o fluxo de aprovação antes de acrescentar mais. Saiba mais sobre a nossa forma de trabalhar.
Fale-nos dos seus fluxos de encomendas e faturas
Escolha um processo e os países onde corre. Mapeamos consigo os sistemas, as interfaces e as exceções e propomos uma primeira versão que funcione em todas as suas empresas.