Aplicação de desembolsos
Aplicar é o ato de informar à REDA Financials quais faturas um pagamento liquida. É o que transforma "enviamos US$ 10.000 para a Apex Construction" em "a fatura da reforma agora está metade paga". Este artigo cobre as três formas de aplicação — automática, manual e na criação — além de pagamentos parciais, um pagamento para várias faturas e como desfazer uma aplicação incorreta.
Acesso necessário. Aplicações criam e alteram registros de subrazão, portanto exigem o conjunto de permissões Accounts Payable v2 ou Accounting Admin v2 (administradores do sistema). Os conjuntos Accounting Controller v2, Accounts Receivable v2 e Read Only v2 podem revisar aplicações, mas não criá-las nem removê-las.
Rota 1 — Automática (o padrão)
Todo formulário de pagamento traz uma caixa de seleção Auto Apply Disbursement, marcada por padrão. Deixe-a ativada e, no momento em que o pagamento é contabilizado, a REDA Financials o aplica para você:
- Está pagando a partir do botão New Disbursement de uma fatura? Essa fatura é liquidada primeiro.
- Qualquer valor restante se distribui pelas demais faturas em aberto do fornecedor, as mais antigas primeiro — a menos que uma fatura carregue uma Application Priority, que fura a fila.
- O mecanismo respeita as salvaguardas da sua contabilidade: períodos de contas a pagar fechados são ignorados, e se Enforce Dimension Match On Apply estiver marcado, apenas faturas com dimensões de custo correspondentes são consideradas.
Veja o pagamento de progresso de US$ 10.000 da Meridian para a Apex Construction logo após a contabilização — aplicado sem um único clique extra:
Rota 2 — Manual (você escolhe a correspondência)
Desmarque a aplicação automática quando quiser controle — ou quando o pagamento chegou como um adiantamento e as contas vieram depois. Então, no pagamento contabilizado, clique em Apply Disbursement:
Revise as faturas em aberto do fornecedor
A tela de aplicação lista todas as faturas contabilizadas desse fornecedor com saldo pendente e cuja data de emissão já chegou — com datas, referências e valores, para que você possa conferir com o aviso de remessa do fornecedor.
Informe os valores a aplicar
Digite quanto do pagamento vai para cada fatura. Aplique o saldo total ou menos para uma liquidação parcial — o total acumulado mantém você dentro do valor não aplicado do pagamento.
Confirme
Cada aplicação entra em vigor imediatamente: os saldos das faturas caem, o aging é atualizado, e o Unapplied Amount do pagamento diminui. Na sua contabilidade, o dinheiro aplicado sai de Supplier Prepayments para liquidar Accounts Payable.
Rota 3 — Na criação, a partir da fatura
O caso do dia a dia que você provavelmente já usou: clique em New Disbursement na fatura em aberto, e o formulário de pagamento chega pré-vinculado a ela com a aplicação automática ativada. Contabilize uma vez; pago e aplicado. O passo a passo está em Criando um Desembolso.
O que uma aplicação registra
Seja qual for a forma de criação, cada aplicação é um pequeno registro com quatro informações:
| Campo | Obrigatório? | O que faz |
|---|---|---|
| Valor aplicado | Sim | Quanto do pagamento liquida essa fatura — limitado pelo valor não aplicado do pagamento de um lado e pelo saldo pendente da fatura do outro |
| Valor do desconto | Não | Um desconto por pagamento antecipado tomado junto — a fatura é liquidada por aplicado + desconto, mas apenas o valor aplicado foi de fato gasto; o desconto é contabilizado na sua conta de Purchase Discounts (detalhes) |
| Data de aplicação | Sim | A data contábil da liquidação — normalmente a data do pagamento |
| Período contábil | Sim (derivado) | Em qual período a liquidação recai, derivado da Application Date |
E na contabilidade, cada aplicação move o dinheiro da conta de retenção para as contas a pagar do fornecedor — para a aplicação de US$ 10.000 da Apex:
| Conta | Débito | Crédito |
|---|---|---|
| Accounts Payable — Trade | US$ 10.000,00 | |
| Supplier Prepayments | US$ 10.000,00 |
(Organizações que equilibram o livro razão por centro de custo veem um par extra de linhas de Dimension Clearing mantendo o saldo a pagar de cada dimensão em equilíbrio — automaticamente.)
Os cenários que costumavam ser difíceis
| Cenário | Como funciona |
|---|---|
| Pagamento parcial | Aplique menos do que o saldo da fatura. A fatura permanece em aberto pelo restante e continua envelhecendo no aging. A fatura de reforma de US$ 48.000 da Meridian foi liquidada em duas transferências — US$ 24.000, depois US$ 10.000 — e mostra US$ 14.000 pendentes. |
| Um pagamento, várias contas | Adicione uma aplicação por fatura até o pagamento se esgotar. Típico em execuções mensais de fornecedores. |
| Adiantamento / depósito | Contabilize o pagamento com a aplicação automática desativada e sem aplicações. Ele permanece 100% não aplicado — um ativo de pagamento antecipado — até que as contas cheguem e você o aplique. |
| Desconto por pagamento antecipado | Registre o desconto na aplicação — você paga menos dinheiro e a fatura ainda é liquidada por completo. Detalhes em Descontos de Pagamento Antecipado e Condições. |
As regras de correspondência
A tela de aplicação só oferece o que as regras permitem, então você raramente esbarra nelas — mas elas explicam por que uma fatura está faltando na lista:
| A regra | O que significa |
|---|---|
| Ambos os documentos devem estar contabilizados | Um pagamento em rascunho não retém dinheiro; uma fatura em rascunho não tem saldo a liquidar. |
| Mesmo fornecedor | O dinheiro da CityClean nunca pode pagar a conta da Summit — um pagamento se aplica somente às faturas do seu próprio fornecedor. |
| Mesma entidade (normalmente) | Cada empresa liquida suas próprias contas a pagar. A exceção deliberada está abaixo. |
| Nunca mais do que está disponível | Uma aplicação não pode exceder o valor não aplicado do pagamento, nem o saldo pendente da fatura — limites rígidos, não avisos. |
| O Accounting Period deve estar aberto para contas a pagar | Liquidações são eventos contábeis; aplicações datadas em um período de contas a pagar fechado são recusadas, e o mecanismo de aplicação automática as ignora. |
| Nunca antes da data da conta ou do pagamento | A data da aplicação não pode ser anterior à fatura que ela liquida nem ao desembolso do qual se origina — o saldo a pagar ficaria negativo em cada data intermediária. Uma conta com data futura nunca aparece na lista e nunca é liquidada automaticamente; mantenha o pagamento não aplicado e aplique-o na data da conta ou depois dela. |
| As dimensões coincidem — se o pagamento assim exigir | Com Enforce Dimension Match On Apply marcado, apenas faturas que carregam as dimensões de custo do pagamento se qualificam. |
A exceção: pagar a conta de outra empresa
Quando uma entidade da Meridian paga uma conta que está na contabilidade de uma entidade irmã, a aplicação pode cruzar entidades — mas somente quando ambas as entidades têm Allow Cross-Entity Settlement (AP) ativado. A aplicação então registra a escrituração intercompany para você: a entidade pagadora registra um Intercompany Receivable (a irmã lhe deve dinheiro) e a entidade da fatura registra um Intercompany Payable — usando as contas intercompany configuradas de cada entidade. Exclua a aplicação e esses lançamentos são revertidos junto. Notas de fornecedor nunca cruzam entidades. O fluxo completo está em Liquidação de Contas a Pagar entre Empresas.
Desfazendo uma aplicação
Aplicou na fatura errada? Abra a guia Aplicações do pagamento e exclua a aplicação incorreta — o saldo da fatura volta, e o valor não aplicado do pagamento retorna para que você possa aplicá-lo corretamente. (Reabrir ou cancelar qualquer um dos documentos também desfaz suas aplicações automaticamente.)
Erros comuns a evitar
| Erro | Por que prejudica | Faça isto em vez disso |
|---|---|---|
| Pagar em dinheiro enquanto a nota de crédito do fornecedor está sem uso | Você envia dinheiro que não devia; o crédito fica parado | Aplique notas de fornecedor primeiro — depois pague apenas o líquido |
| Deixar um adiantamento sem correspondência depois que suas contas chegam | A fatura envelhece como não paga enquanto o pagamento antecipado fica ocioso — o extrato do fornecedor e seu aging enganam | Quando a conta é contabilizada, abra o pagamento e aplique-o (ou deixe a aplicação automática cuidar disso) |
| Forçar uma correspondência aproximada ("só uns poucos dólares de diferença") | Uma aplicação afirma o mesmo dinheiro; a diferença geralmente é uma taxa ou disputa que agora fica escondida dentro de uma correspondência errada | Aplique somente o valor real; resolva a diferença em seus próprios termos |
| Retroceder a Application Date por descuido | A liquidação recai na contabilidade de um período anterior e distorce o histórico de contas a pagar — e ela nunca pode ficar antes da conta ou do próprio pagamento, ou o saldo a pagar fica negativo no intervalo | Use a data do pagamento como padrão; retroceda apenas para um período genuinamente aberto, e nunca antes da data da fatura ou da data do desembolso |
| "Corrigir" correspondências erradas cancelando o pagamento inteiro | O cancelamento desfaz tudo — inclusive as aplicações corretas — e consome um número de cheque à toa | Exclua apenas a aplicação errada e reaplique; o pagamento em si está correto |
O que vem a seguir
- Descontos de Pagamento Antecipado e Condições — a mecânica do desconto.
- Execução do Lote de Pagamentos — aplicações em escala.
- Aplicando Notas de Crédito de Fornecedor — a mesma ideia, com créditos em vez de dinheiro.
- Lotes de Aplicação Automática — agendando aplicação automática em toda a organização.
Perguntas frequentes
Exclua a aplicação na guia Aplicações do pagamento e aplique manualmente na fatura correta. Se isso continuar acontecendo, defina uma Application Priority nas faturas que devem ser liquidadas primeiro — o mecanismo de aplicação automática a respeita antes de recorrer ao critério padrão de mais antiga primeiro.
Só se qualificam faturas contabilizadas com saldo pendente. Rascunhos, contas totalmente liquidadas e notas de fornecedor não aparecem. Uma fatura com data futura também fica retida até que sua data de emissão chegue — não há contas a pagar a liquidar antes disso. Se a correspondência de dimensões estiver imposta no pagamento, faturas com valores de centro de custo diferentes também são filtradas.
Não — um pagamento pertence a um único fornecedor e se aplica apenas às faturas desse fornecedor. Pagar dois fornecedores significa dois pagamentos (que é exatamente o que uma execução de pagamentos em lote automatiza).
Sua Application Date — normalmente a data do pagamento — que posiciona a liquidação em um período contábil. É assim que o aging de contas a pagar e os extratos de fornecedor permanecem historicamente precisos mesmo quando você aplica com atraso.
Informe-o como o Discount Amount da aplicação: a fatura é liquidada pelo valor aplicado mais o desconto, e o desconto é contabilizado na sua conta de Purchase Discounts como receita. As execuções de pagamento sugerem descontos elegíveis automaticamente — veja Descontos de Pagamento Antecipado e Condições.
Três lugares consistentes: a guia Aplicações do pagamento, a guia Aplicações de cada fatura e os lançamentos no livro razão nas listas de Accounting Transactions. Toda aplicação registra seu valor, data e período contábil.
Use uma Application Date atual e aberta — a liquidação é um evento de hoje, mesmo que o pagamento tenha sido anterior. Períodos de contas a pagar fechados recusam novas aplicações (e remoções) nos dois sentidos; se você realmente acredita que o período deveria ser reaberto, converse com seu controller.
Isso foi útil?