Funcionalidade de Cartão de Crédito

A ambiguidade de status vem de tentar representar dois fatos com um campo só. Sem modelar isso, a conciliação bancária e o contas a pagar vão mostrar números diferentes da DRE.

Usar status próprio para origem cartão, como "Pago no cartão · aguardando fatura" → "Quitado". Tratar o saldo das faturas em aberto como obrigação (cartões a pagar) na visão de caixa e na projeção.

Foi o caso que motivou a reunião, e a solução por seleção não o resolve por completo. O banco não aloca o pagamento por item: quando o cliente paga R$ 4 mil de R$ 5 mil, o restante vai para a fatura seguinte com juros, IOF e multa. Nenhuma compra fica "não paga".

Aceitar também pagamento por valor. A diferença vira "saldo transportado" na próxima fatura, com lançamento automático ou assistido de juros, IOF e multa em despesas financeiras. A seleção de itens fica para antecipação de parcelas.

Se a DFC mostrar só "Pagamento de fatura", a análise de caixa por categoria, que é o produto da Extat, se perde, porque o dinheiro saiu para marketing, software, alimentação etc.

Na DFC, abrir o pagamento da fatura pelas categorias das transações baixadas. No pagamento parcial, ratear proporcionalmente ou seguir a seleção.

O próprio exemplo da reunião (TV, computador) é investimento. Lançado como despesa, joga o valor cheio na DRE do mês e distorce margem e EBITDA.

Categorias de investimento ficam fora da DRE operacional e entram na DFC como atividade de investimento, conforme o plano de contas padrão Extat.

As parcelas restantes informadas na implantação são de compras antigas. Se receberem competência dos meses futuros ou do mês de implantação, poluem a DRE do primeiro mês do cliente.

Registrar a data original da compra ou marcar como "saldo de implantação", que afeta só caixa e fatura. Deixar a regra explícita na tela.

A regra "só a fatura corrente" bloqueia um caso comum: a compra feita dia 8 e lançada dia 12, depois do fechamento. Ela pertence à fatura já fechada, e o BPO lança com atraso o tempo todo.

Calcular a fatura automaticamente a partir da data da compra × fechamento. Permitir lançar em fatura fechada e ainda não paga, com aviso. Bloquear só fatura já quitada.

Bancos mudam fechamento e vencimento conforme fim de semana, feriado ou calendário próprio, e o cliente pode trocar o dia de vencimento.

Permitir ajustar fechamento e vencimento por fatura. Definir o que acontece com faturas abertas quando o cadastro do cartão muda (recalcular só as futuras).

Padronizar: Aberta → Fechada → Paga / Parcialmente paga / Vencida, com regras do que se pode lançar, editar e desfazer em cada estado. Isso também orienta os alertas.

Definir onde fica o centavo: R$ 1.000 em 3x = 333,33 + 333,33 + 333,34 (diferença na última). Garantir que a soma seja exatamente o valor da compra.

Hoje a fatura só aceita despesas. Estorno de compra, cancelamento com parcelas futuras, cashback e crédito de pagamento a maior reduzem a fatura e precisam refletir na DRE.

Criar lançamento "crédito na fatura" vinculado à compra original. No cancelamento, remover ou estornar as parcelas futuras em grupo.

Com o split (D01), editar valor, categoria, número de parcelas ou cartão precisa de uma regra. O que acontece se uma parcela já estiver em fatura paga?

Tratar a compra como grupo: editar propaga para as parcelas não quitadas e trava as quitadas. Oferecer "esta parcela" ou "esta e as seguintes", como nas recorrências.

Prever categorias e lançamento guiado para anuidade, tarifas, juros de parcelamento com juros (valor total maior que à vista), IOF e compras em moeda estrangeira (câmbio e IOF).

Citada pelo Gabriel sem regra definida: trazer parcelas futuras para a fatura atual, com eventual desconto registrado como receita financeira ou redutor.

Não há como conferir a fatura lançada contra a real. Sem isso, o BPO não fecha o mês com segurança.

Importar a fatura (CSV/OFX, e depois Open Finance), casar item a item com os lançamentos, apontar divergências (faltando, sobrando, valor diferente) e só então permitir pagar.

Bloquear pagamento sem saldo é arriscado quando o saldo inicial foi mal parametrizado ou a conta tem cheque especial. O usuário simplesmente não consegue registrar um pagamento que já aconteceu no banco.

Avisar em vez de bloquear (ou bloquear só com permissão), permitir limite de cheque especial por conta e oferecer "ajustar saldo" com registro de auditoria.

O limite é cadastrado mas não usado. A compra parcelada consome o valor cheio e libera conforme as faturas são pagas. Mostrar limite disponível e alertar perto do teto.

Uma fatura com vários cartões físicos ou virtuais e portadores diferentes. Permitir identificar o portador e o centro de custo por lançamento, útil para prestação de contas interna.

Definir quem pode pagar, desfazer pagamento, editar fatura fechada e ajustar saldo, com log de cada ação, não só no "desfazer".

Situação frequente nos clientes Extat: marcar como "pessoal do sócio" e gerar conta a receber ou retirada de pró-labore, para não contaminar a DRE.

As parcelas já comprometidas devem aparecer no fluxo de caixa projetado e no contas a pagar por vencimento de fatura. É base para o insight de "previsão de 3 meses" citado na reunião.

Integrar a futura funcionalidade de recorrência: SaaS e assinaturas lançadas automaticamente em cada fatura.

Definir layout do CSV, deduplicação e mapeamento de categorias. Na API, garantir idempotência nos lotes de pagamento, o que é crítico quando um agente de IA repete um comando.

Avisar que a fatura fecha em X dias, que vence amanhã, que o saldo é insuficiente para a fatura e que há lançamentos sem categoria.