O seu ERP consegue cruzar pedidos de compra, receções e faturas? Lista prática de avaliação

O que a conferência a três vias verifica — e o que não garante

A conferência a três vias refere-se, em geral, à comparação entre uma fatura de fornecedor, um pedido de compra e um registo de mercadorias recebidas. Num fluxo de compras a pagamento descrito, a equipa de contas a pagar confere as faturas com os pedidos de compra e os registos de receção de mercadorias; as faturas que correspondem aos registos avançam para o processamento do pagamento [2]. Considere isto um exemplo de fluxo de trabalho, não uma garantia de que todos os ERP utilizam as mesmas regras.

A conferência pode ajudar a identificar incoerências entre os registos do pedido, da receção e da fatura. Por si só, não permite determinar se as mercadorias podem ser utilizadas, se um serviço foi satisfatório, se um fornecedor é legítimo ou se o tratamento fiscal está correto. Os seus controlos de receção, aprovação, fornecedores e contabilidade continuam a ser importantes.

Não parta do princípio de que todos os ERP comparam os mesmos campos ou aplicam as mesmas regras. A comparação pode ser feita ao nível das linhas, do total do documento ou de ambos; pode usar tolerâncias configuradas ou exigir que uma pessoa resolva as divergências. Teste o comportamento de que precisa, em vez de confiar no nome de uma funcionalidade.

• Pedido de compra: verifique que campos são utilizados, como o artigo ou serviço, a quantidade pedida, o preço unitário e o total da linha ou do pedido.
• Receção: verifique de que forma as quantidades e os valores registados servem de base à fatura e se mais do que uma receção pode estar associada a um pedido.
• Fatura: verifique que quantidades, preços, totais e outros encargos relevantes são comparados.
• Decisão: determine se uma correspondência apenas assinala um estado, permite a aprovação ou pode encaminhar uma fatura para o processo de pagamento.

Mapeie o processo de compras a pagamento, os papéis e os limites de aprovação antes de testar

Antes de abrir uma demonstração, registe por escrito como decorre uma compra na sua organização. Inclua quem a solicita, quem a aprova, quem faz o pedido, quem regista a receção, quem trata das faturas e quem autoriza o pagamento. Um teste só é significativo se o ERP for avaliado em função das responsabilidades e da separação de funções que a sua organização realmente exige.

Defina os limites e as exceções relevantes para a sua empresa. Registe os limites de aprovação, as divergências permitidas de preço ou quantidade, as evidências exigidas para serviços e as regras aplicáveis à alteração de um pedido após a aprovação. Se ainda não tiver uma política, assinale a decisão como pendente, em vez de presumir que a configuração predefinida do ERP é adequada.

Os requisitos variam consoante a organização e a jurisdição. Peça às pessoas responsáveis pela contabilidade, pelas compras e pela conformidade que identifiquem os requisitos locais aplicáveis, incluindo regras relativas a faturas, impostos, conservação de registos ou aprovações. Não trate a descrição geral de um fluxo de trabalho pelo fornecedor como aconselhamento jurídico ou contabilístico.

• Desenhe o percurso habitual, desde o pedido até ao pedido de compra, à receção, à análise da fatura, à aprovação e ao pagamento.
• Identifique a pessoa responsável por cada ação, incluindo quem pode alterar um pedido de compra ou uma receção.
• Defina limites de aprovação representativos e identifique quem pode autorizar uma exceção.
• Enumere os registos que precisa de conservar e as pessoas que precisam de lhes aceder.
• Identifique questões específicas da jurisdição a esclarecer com um consultor qualificado ou com a autoridade competente.

Prepare casos de teste representativos: correspondência exata, receção parcial, divergência, nota de crédito e fatura duplicada

Prepare um conjunto pequeno e repetível de testes com dados fictícios de fornecedores e transações. Inclua transações sem problemas e casos excecionais. Para cada caso, registe os documentos e valores introduzidos, o resultado esperado e as evidências que irá recolher. Utilize os mesmos casos para cada ERP candidato, de modo a permitir uma comparação justa.

Inclua explicitamente entregas parciais. Por exemplo, peça uma determinada quantidade, registe a receção de apenas uma parte e teste uma fatura referente à quantidade recebida, bem como outra referente à quantidade total pedida. Em seguida, registe uma receção posterior e teste como é tratada a quantidade restante. A avaliação deve mostrar como o ERP relaciona várias receções e faturas e o que permite em cada etapa.

Sempre que possível, altere uma condição de cada vez. É mais fácil avaliar uma pequena diferença controlada de preço do que um caso que altera simultaneamente o preço, a quantidade e os custos de transporte. Depois, acrescente combinações mais complexas que se aproximem das suas transações reais.

• Correspondência exata: a quantidade e o preço da fatura coincidem com o pedido de compra e a receção registada.
• Receção parcial: a fatura abrange apenas a parte recebida; em seguida, teste uma fatura que exceda a quantidade registada como recebida.
• Divergência de preço: o preço unitário da fatura é diferente do preço do pedido, mas a quantidade coincide.
• Divergência de quantidade: a quantidade da fatura é diferente da quantidade recebida ou da quantidade pedida.
• Crédito ou ajuste: teste como uma nota de crédito ou um ajuste do fornecedor se relaciona com a fatura e o pedido originais.
• Duplicado: submeta a mesma fatura duas vezes e, em seguida, teste uma repetição com uma referência ou formatação alterada, se isso refletir o seu risco.
• Encargos adicionais: se for relevante, teste separadamente custos de transporte, impostos, descontos ou outros encargos e confirme como afetam a comparação e a aprovação.

Verifique como o ERP identifica as divergências e afeta a aprovação ou o pagamento

Em cada teste, observe o que o sistema compara e comunica. Registe se identifica o documento, a linha e o campo afetados; se apresenta os valores esperados e introduzidos; e se o utilizador consegue perceber que ação é necessária. Um estado genérico de «exceção» pode não ser suficiente se os colaboradores tiverem de procurar em vários registos para compreender o problema.

Teste as consequências de cada resultado, não apenas o aviso. Uma exceção impede a aprovação, bloqueia o pagamento ou limita-se a aparecer numa lista? Uma pessoa autorizada pode prosseguir? O comportamento é diferente para uma pequena divergência e para uma divergência significativa? Não parta do princípio de que um aviso constitui um controlo de pagamento ou de que um estado de bloqueio não pode ser substituído.

Peça ao fornecedor que explique quais as regras de conferência configuráveis e quais são fixas. Confirme se as tolerâncias se aplicam por valor, percentagem, quantidade, linha ou documento e se os impostos ou outros encargos são tratados separadamente. Registe exatamente o que verificou; evite tirar conclusões gerais com base num único exemplo bem-sucedido.

• Registe o resultado do sistema para cada caso sem problemas e cada caso excecional.
• Verifique se a divergência está visível para a pessoa que deverá resolvê-la.
• Siga a fatura ao longo do fluxo de trabalho o suficiente para confirmar se a aprovação ou o pagamento ficam retidos.
• Repita um caso de divergência imediatamente abaixo e imediatamente acima de qualquer tolerância proposta.
• Teste se a alteração de um pedido, de uma receção ou de uma fatura após a correspondência altera o estado ou cria um registo visível.

Verifique as permissões, as substituições e as evidências de auditoria

Avalie as pessoas e as permissões envolvidas, não apenas o cálculo de correspondência. Inicie sessão com papéis representativos e experimente as ações relevantes: editar um pedido, registar uma receção, resolver uma divergência, aprovar uma fatura e autorizar um pagamento. Confirme se uma pessoa consegue executar ações que, segundo o seu processo, devem permanecer separadas.

Pergunte o que acontece quando alguém substitui uma decisão relativa a uma divergência. Analise o histórico efetivamente gerado por uma transação de teste e verifique se regista quem agiu, quando, qual foi a transação afetada, o que mudou, o motivo indicado e as aprovações associadas à decisão. Estas são questões para avaliação, não funcionalidades garantidas. Um artigo da ACM descreve um rasto de auditoria no fluxo de ERP que propõe, mas não estabelece que todos os ERP forneçam os mesmos detalhes ou regras de conservação [2].

Confirme as regras de conservação, acesso, exportação e eliminação tendo em conta as necessidades da sua organização em matéria de conservação de registos. Uma descrição de fluxo de trabalho ou uma demonstração do fornecedor não prova que a mesma configuração esteja ativada na instalação candidata.

• Sempre que possível, teste cada papel com uma conta separada; não dependa apenas de uma demonstração feita por um administrador.
• Tente executar ações permitidas e proibidas e registe o resultado.
• Se a sua política assim o exigir, verifique se a substituição de uma decisão requer um motivo ou uma aprovação adicional.
• Analise o histórico resultante e confirme que os utilizadores relevantes lhe conseguem aceder.
• Pergunte como os registos de auditoria são conservados, exportados e protegidos; depois, valide as respostas no ambiente de teste.

Avalie o tratamento de exceções, os relatórios e as exportações em função das necessidades operacionais

A utilidade diária da conferência depende da forma como as exceções são tratadas. Teste se os colaboradores conseguem encontrar faturas por resolver, identificar o motivo de cada bloqueio, consultar o pedido de compra e a receção relacionados, atribuir ou encaminhar o caso e registar a sua resolução. Se o seu fluxo depender do correio eletrónico ou de outra ferramenta, verifique que informações têm de ser transferidas manualmente.

Use questões realistas para avaliar os relatórios: que faturas aguardam uma receção? Quais têm divergências de preço ou quantidade? Que exceções continuam por resolver? As contas a pagar conseguem distinguir uma fatura bloqueada de uma fatura aprovada, mas ainda não paga? Os nomes e a disponibilidade dos relatórios variam, por isso teste se o ERP consegue responder às perguntas que a sua equipa realmente coloca.

Teste as exportações com um período representativo e um pequeno conjunto de transações. Confirme se o resultado inclui os campos, identificadores e estados de que a equipa financeira precisa para reconciliação ou análise adicional. A presença de um campo numa exportação não prova, por si só, que o controlo subjacente tenha funcionado corretamente.

• A equipa consegue localizar as exceções em aberto sem pesquisar individualmente os registos de cada fornecedor?
• Os colaboradores conseguem consultar o pedido, a receção e a fatura relevantes a partir da exceção?
• Consegue identificar o responsável, o tempo decorrido, o motivo e o estado atual de um caso por resolver?
• Os relatórios ou as exportações podem ser filtrados e reconciliados com os registos utilizados no seu processo?
• As correções e resoluções continuam visíveis depois de a exceção original ser encerrada?

Consulte a documentação do fornecedor e teste num ambiente isolado; registe as limitações e as questões específicas da jurisdição

Comece pela documentação oficial do fornecedor para compreender o fluxo de trabalho previsto, as opções de configuração, os pré-requisitos e a terminologia. Por exemplo, um guia de instalação da Hyland enumera campos de pedidos de compra como quantidade pedida, preço unitário e total da linha, bem como quantidades e valores totais da receção de mercadorias e da fatura [1]. Também descreve opções de configuração para obter os dados das linhas dos pedidos de compra a partir de um ficheiro ou de uma base de dados [1]. Estes exemplos podem ajudar a elaborar casos de teste, mas não demonstram que outro ERP tenha os mesmos campos ou comportamento.

Confirme o comportamento num ambiente de teste, utilizando os seus próprios casos. A documentação descreve um produto ou uma configuração; não prova que uma determinada definição esteja ativada na instalação candidata nem que seja adequada ao seu processo. Mantenha um registo de testes com o cenário, a configuração, o papel do utilizador, os passos, o resultado observado, o resultado esperado, as evidências e quaisquer questões em aberto.

No caso das aplicações ERP autoalojadas, avalie a aplicação separadamente do alojamento. Considere quem é responsável pela configuração da aplicação, pelo acesso dos utilizadores, pela governação dos dados e pelos procedimentos de cópia de segurança e recuperação. A infraestrutura gerida pode reduzir o trabalho de infraestrutura, mas não elimina a responsabilidade da sua organização pelas regras de negócio, pelos dados e pelas decisões de acesso.

• Use a documentação oficial como orientação e, em seguida, reproduza o fluxo de trabalho num ambiente isolado ou noutro ambiente de teste seguro.
• Registe a versão da aplicação e a configuração utilizadas no teste.
• Conserve evidências de correspondências bem-sucedidas, exceções, substituições, permissões e exportações.
• Classifique cada requisito como verificado, configurável, não suportado, pouco claro ou ainda dependente de aconselhamento profissional.
• Confirme as questões de contabilidade, impostos, privacidade e conservação de registos com consultores adequados à sua jurisdição.

Lista de verificação para comparar ERP candidatos

Avalie os candidatos com base nos mesmos cenários operacionais, em vez de contar nomes de funcionalidades. Um candidato que trate claramente as suas transações habituais e permita responsabilizar os intervenientes pelas exceções poderá ser mais adequado do que outro com uma lista de funcionalidades mais extensa, mas com um comportamento pouco claro nos pontos mais vulneráveis do seu processo.

Distinga os controlos indispensáveis das preferências. Se um ERP não conseguir demonstrar um limite de aprovação obrigatório, uma substituição rastreável ou um fluxo de trabalho contabilístico específico da jurisdição, registe isso como uma lacuna a resolver — não como uma promessa a retomar depois da adoção. Inclua na decisão o esforço de implementação e a administração contínua.

• Mapeámos as etapas, os papéis e os limites de aprovação do nosso processo de compras a pagamento.
• Testámos correspondências exatas, receções parciais, divergências de preço e quantidade, notas de crédito e duplicados.
• Verificámos o que o sistema compara e o que acontece a uma fatura com uma divergência.
• Testámos as permissões dos papéis, as substituições e as evidências conservadas para cada ação.
• Conseguimos localizar, atribuir, resolver e comunicar exceções de uma forma adequada à nossa equipa.
• As exportações satisfazem as nossas necessidades reais de reconciliação e análise.
• Documentámos dependências de configuração, limitações e questões por esclarecer junto do fornecedor.
• Analisámos os requisitos aplicáveis de contabilidade, impostos, privacidade e conservação de registos com profissionais qualificados.