Cenários de Faturamento do Mundo Real

A vida de faturamento de todo freelancer é mais bagunçada do que um arquivo de configuração limpo sugere. Clientes mudam, contratos são renovados, erros acontecem, e às vezes você faz trabalhos que não quer cobrar. Esses cenários descrevem situações reais e como o Vibes to Bucks lida com cada uma delas.

Cenário 1 — Renovação de contrato: mesmo cliente, novo projeto

Quem: Anna, uma desenvolvedora freelancer trabalhando no github.com/acme/website para o Cliente Acme.

O que aconteceu: Anna tem faturado os custos de IA para o projeto Moneybird “Acme Website Q1–Q2” desde janeiro. Em 1º de julho, um novo contrato de 6 meses entra em vigor. O projeto do cliente no Moneybird muda para “Acme Website Q3–Q4” — possivelmente com uma taxa horária diferente. O repositório e o branch são os mesmos.

O que Anna quer:

• A partir de 1º de julho, todos os novos custos de IA sincronizam com o novo projeto.
• Os seis meses de entradas de tempo já no Moneybird sob o projeto antigo permanecem exatamente onde estão.
• O custo de hoje vai para o novo projeto.

O risco sem orientação: Anna altera sua regra de faturamento e executa o Sync Now. A extensão reagrupa de janeiro a junho, não vê entradas de tempo para esses dias sob o novo projeto e cria 180 entradas duplicadas no Moneybird — junto com as que já existem sob o projeto antigo.

Como o Vibes to Bucks lida com isso: Quando Anna edita sua regra de faturamento para apontar para o novo projeto, a extensão pergunta o que deve acontecer com os custos históricos. Ela escolhe “Aplicar a partir de hoje”. Dias passados mantêm sua associação com o projeto antigo. Apenas hoje e dias futuros sincronizam sob o novo projeto. Sem duplicatas, sem necessidade de limpeza.

Cenário 2 — Troca de cliente: mover um repo para um cliente diferente

Quem: Ben, um desenvolvedor trabalhando no github.com/org/platform.

O que aconteceu: Ben inicialmente faturou este repo para o Cliente Alpha, que financiou a fase de P&D. A plataforma agora está em produção e o Cliente Beta é o cliente contínuo. Ben precisa remapear o repositório.

2a — Ruptura limpa

O que Ben quer: Custos futuros vão para o Cliente Beta. Entradas passadas sincronizadas com o Cliente Alpha permanecem intocadas. Nada retroativo.

Como o Vibes to Bucks lida com isso: Ben muda o contato da regra de faturamento de Alpha para Beta. A extensão pergunta o que deve acontecer com o histórico. Ele escolhe “Aplicar a partir de hoje”. As entradas históricas de Alpha permanecem no Moneybird. Beta começa a receber entradas a partir de hoje.

2b — Correção retroativa completa

O que Ben quer: O faturamento Alpha foi um erro — deveria ter sido Beta desde o início. Ben quer ressincronizar tudo sob Beta. Ele aceita que precisará limpar manualmente as entradas de Alpha no Moneybird.

Como o Vibes to Bucks lida com isso: Ben escolhe “Aplicar a todo o tempo”. A extensão o avisa que as entradas existentes sob Alpha não serão automaticamente deletadas — ele precisará removê-las no Moneybird. Em seguida, cria novas entradas para cada dia histórico sob Beta.

2c — Sincronizar apenas o intervalo

O que Ben quer: Ben parou de sincronizar duas semanas atrás quando percebeu que o mapeamento estava errado. Ele tem 14 dias de custo não sincronizado no livro razão. Ele quer que esses 14 dias vão para Beta, mas os meses já sincronizados com Alpha devem permanecer.

Como o Vibes to Bucks lida com isso: Ben escolhe “Aplicar apenas aos dias não sincronizados”. A extensão sabe quais dias já têm uma entrada de tempo em provider_posts e os ignora. Apenas os 14 dias não sincronizados são criados sob Beta.

Cenário 3 — Divisão de projeto: redistribuir trabalho entre subprojetos

Quem: Clara, uma desenvolvedora trabalhando em um monorepo para o Cliente Gamma.

O que aconteceu: Clara tem faturado todo o trabalho de IA para um projeto abrangente “Desenvolvimento Geral”. Gamma agora quer que os custos sejam divididos por área de funcionalidade. Clara cria regras de faturamento baseadas em branch: feature/auth/* → “Módulo de Autenticação” e feature/billing/* → “Módulo de Faturamento”.

3a — Divisão apenas para frente

O que Clara quer: Daqui para frente, os custos são direcionados para o subprojeto correto. Custos passados já sincronizados sob “Desenvolvimento Geral” permanecem lá.

Como o Vibes to Bucks lida com isso: Quando Clara adiciona as novas regras de branch, a extensão pergunta sobre o histórico para cada uma. Ela escolhe “Aplicar a partir de hoje” para ambas. Entradas históricas sob “Desenvolvimento Geral” permanecem intocadas.

3b — Precisão histórica

O que Clara quer: Ela realmente quer mover retroativamente os custos passados para os subprojetos corretos. Ela aceita que vai deletar manualmente as entradas antigas de “Desenvolvimento Geral” no Moneybird.

Como o Vibes to Bucks lida com isso: Clara escolhe “Aplicar a todo o tempo” para as novas regras. A extensão avisa sobre as entradas existentes sob o projeto antigo e cria entradas corretas por subprojeto por dia. Clara limpa as entradas antigas no Moneybird.

Cenário 4 — Trabalho de cortesia não faturável

Quem: David, um freelancer trabalhando no repo do Cliente Delta.

O que aconteceu: David é envolvido em uma revisão de código interna e algumas experimentações que não fazem parte do escopo de Delta — mas ele mantém o Cursor aberto no repo deles. Ele não quer que as próximas 2 horas de custo de IA sejam cobradas de Delta.

O que David quer:

• Alternar a regra de faturamento de Delta para o modo “não faturável”. Um indicador visível na barra de status confirma que a regra é não faturável.
• Os custos de IA ainda são rastreados e visíveis no painel — ele quer ver quanto esse trabalho de cortesia custa para ele — mas marcados como não para faturamento.
• A cada hora, uma notificação de lembrete: “Regra de faturamento de Delta está não faturável há 2 horas. Ainda trabalhando não faturável?”
• Quando ele alterna de volta para faturável, a sincronização normal é retomada.
• Os custos não faturáveis aparecem no painel sob Delta, mas são claramente distinguidos dos custos faturáveis.

Por que por mapeamento, não global: David pode estar multitarefando. Se ele mudar para o repo do Cliente Beta enquanto Delta está não faturável, Beta deve continuar faturando normalmente. Não faturável é uma decisão de cortesia por cliente: “esse custo que estou gerando não é pedido do cliente — estou fazendo isso por eles como uma cortesia.”

Como o Vibes to Bucks lida com isso: David abre o painel de Configurações e alterna a regra de faturamento de Delta para não faturável. Um diálogo pergunta duas coisas: quando o não faturável deve começar (agora ou retroativo) e quando deve terminar. David escolhe “A partir de agora” e “Fim do dia” — o faturamento é retomado automaticamente amanhã. A barra de status mostra $4.23 hoje · Delta [não faturável até o fim do dia] enquanto ele trabalha no repo de Delta. Custos não faturáveis ainda são sincronizados com o Moneybird como entradas de tempo não faturáveis (visíveis nos registros, mas excluídas da fatura do cliente). O painel mostra tanto os custos faturáveis quanto os não faturáveis para Delta, claramente separados.

Se David espera que o trabalho de cortesia dure mais, ele pode escolher “Data específica” (por exemplo, não faturável até sexta-feira) ou “Até eu retomar manualmente” com um intervalo de lembrete (a cada 30 minutos, 1 hora, 2 horas, etc.) para não esquecer de reativar o faturamento.

Variação — não faturável retroativo

O que David quer: Ele esqueceu de alternar antes de começar. Ele quer marcar os últimos 90 minutos como não faturáveis após o fato.

Como o Vibes to Bucks lida com isso: David abre o painel de Configurações, alterna Delta para não faturável e na seção Início escolhe “Retroativo” com um horário de 90 minutos atrás. Custos a partir desse ponto são marcados como não faturáveis. Se a entrada de tempo de hoje já foi sincronizada com o Moneybird, a extensão recalcula e atualiza para refletir o valor faturável reduzido. O retroativo é limitado a hoje — para correções de vários dias, o Sync Ledger oferece controles de desfazer e ressincronizar.

Cenário 5 — Desfazer uma sincronização incorreta

Quem: Eve, uma freelancer que mudou um mapeamento e imediatamente executou o Sync Now.

O que aconteceu: Eve editou uma regra de faturamento (mudou o projeto) e executou o Sync Now sem pensar nas consequências. A extensão criou 3 meses de novas entradas de tempo sob o projeto errado no Moneybird, junto com as entradas corretas existentes sob o projeto antigo.

O que Eve quer:

• Ver o que foi sincronizado — um resumo mostrando quantas entradas foram criadas ou atualizadas, para quais dias, sob qual projeto.
• Reverter: ou a extensão deleta as entradas criadas incorretamente, ou informa claramente quais IDs de entrada ela deve limpar manualmente.

Como o Vibes to Bucks lida com isso: Após cada sincronização, a extensão mostra uma notificação: “Sincronizado com Moneybird — Criado 87, atualizado 2, ignorado 14.” Clicar em “Mostrar detalhes” abre o Sync Ledger — uma visão dedicada mostrando cada entrada sincronizada e pendente, filtrável por cliente, projeto e data. Eve pode ver exatamente quais entradas foram criadas, selecionar as incorretas e clicar em “Desfazer sincronização.” A extensão deleta essas entradas do Moneybird e as marca como pendentes novamente para que possam ser ressincronizadas corretamente após ela corrigir a regra.

Cenário 6 — Faturamento temporário de projeto

Quem: Frank, um desenvolvedor trabalhando no github.com/acme/api.

O que aconteceu: Frank normalmente fatura para o projeto “Manutenção de API”. Por duas semanas em março, ele está em um sprint especial faturado para “Migração API v2”. Após o sprint, ele volta ao normal.

O que Frank quer:

• Mudar a regra de faturamento para “Migração API v2” em 10 de março.
• Mudar de volta para “Manutenção de API” em 24 de março.
• Apenas o período de 10 a 23 de março sincroniza com “Migração API v2”.
• Tudo antes de 10 de março e após 23 de março sincroniza com “Manutenção de API”.
• Sem bagunça retroativa em nenhuma direção.

Como o Vibes to Bucks lida com isso: Ambas as vezes que Frank muda a regra de faturamento, ele escolhe “Aplicar a partir de hoje”. Em 10 de março, a regra começa a faturar para “Migração API v2”. Em 24 de março, ela volta para “Manutenção de API”. As entradas de cada período permanecem com o projeto que estava ativo na época.

Cenário 7 — Parar de faturar, continuar rastreando

Quem: Gina, uma freelancer encerrando com o Cliente Eta.

O que aconteceu: O contrato acabou, mas Gina ainda faz manutenção menor no repo de Eta. Ela quer ver os custos de IA no painel — para avaliar se um novo contrato valeria a pena — mas não quer sincronizar nenhuma entrada de tempo.

O que Gina quer:

• Marcar a regra de faturamento como permanentemente não faturável (não um alternador temporário — uma configuração duradoura).
• O painel ainda mostra custos atribuídos ao Cliente Eta.
• A sincronização ignora completamente essa regra de faturamento.
• Se Eta voltar com um novo contrato, ela muda de volta para faturável e só sincroniza a partir desse ponto — não o período de lacuna.

Como o Vibes to Bucks lida com isso: Gina desmarca “Faturável” na regra de faturamento de Eta. Os custos continuam a ser rastreados e aparecem no painel sob Eta, mas nenhuma entrada de tempo é criada. Quando um novo contrato chega, ela reativa o faturamento e escolhe “Aplicar a partir de hoje”. A lacuna não faturável permanece não faturada.

Cenário 8 — Migração de provedor

Quem: Hugo, um freelancer que tem sincronizado com o Moneybird por 6 meses.

O que aconteceu: A firma de contabilidade de Hugo o muda para o Harvest. Ele altera destination: harvest em sua configuração e configura novas regras de faturamento no Harvest.

O que Hugo quer:

• Daqui para frente, a sincronização vai para o Harvest.
• Os 6 meses de entradas no Moneybird permanecem intocados.
• Nenhuma entrada retroativa criada no Harvest para o período histórico.

Como o Vibes to Bucks lida com isso: Quando Hugo muda o provedor de faturamento, a extensão detecta que o Harvest não tem histórico de sincronização. Sem orientação, tentaria criar entradas para cada dia histórico. Em vez disso, o mesmo diálogo de três opções aparece: “Começar do zero a partir de hoje”, “Sincronizar todo o histórico”, ou “Sincronizar apenas dias não sincronizados.” Hugo escolhe “Começar do zero.” A extensão define uma data de corte de migração para que o mecanismo de sincronização ignore todos os dias antes de hoje. Apenas hoje e dias futuros criam entradas no Harvest. As entradas no Moneybird permanecem intocadas.

Cenário 9 — Exclusão acidental de regra

Quem: Ivan, um freelancer faturando o repo do Cliente Kappa.

O que aconteceu: Ivan queria editar sua regra de faturamento para mudar a taxa horária, mas acidentalmente a excluiu. Ele percebe imediatamente e recria a regra com as configurações corretas.

O que Ivan quer:

• Recriar a regra sem causar meses de entradas de tempo duplicadas no Moneybird.
• Entradas passadas que já foram sincronizadas devem permanecer intocadas.
• O faturamento deve continuar sem interrupções, como se nada tivesse acontecido.

O risco sem orientação: Ivan cria a nova regra. A extensão vê um repo com dados de custo históricos e sem histórico de regra de faturamento correspondente. Uma sincronização ingênua trataria cada dia passado como “nunca sincronizado sob esta regra” e criaria entradas para todo o histórico.

Como o Vibes to Bucks lida com isso: Quando Ivan cria uma regra de faturamento para um repo que já tem dados de custo históricos no livro razão, a extensão reconhece isso e apresenta o mesmo diálogo de três opções. Ivan escolhe “Aplicar a partir de hoje” — as entradas passadas permanecem como estavam, e o faturamento é retomado a partir de hoje. Sem duplicatas, sem lacunas, sem pânico.

O fio comum

Cada cenário acima se resume a uma pergunta: quando você muda uma regra de faturamento, o que deve acontecer com o passado?

O Vibes to Bucks nunca toma essa decisão por você. Cada vez que você edita uma regra de faturamento — muda o cliente, projeto, taxa ou status de faturamento — a extensão pede que você escolha:

Essa escolha guiada aparece em um diálogo claro sempre que uma mudança de regra de faturamento afetaria como os custos históricos são tratados. Sem surpresas, sem refaturamento retroativo silencioso, sem duplicatas órfãs.