Escenarios de Facturación del Mundo Real

La vida de facturación de cada freelancer es más desordenada de lo que sugiere un archivo de configuración limpio. Los clientes cambian, los contratos se renuevan, ocurren errores y, a veces, haces trabajo por el que no quieres cobrar. Estos escenarios describen situaciones reales y cómo Vibes to Bucks maneja cada una.

Escenario 1 — Renovación de contrato: mismo cliente, nuevo proyecto

Quién: Anna, una desarrolladora freelance trabajando en github.com/acme/website para el Cliente Acme.

Qué pasó: Anna ha estado facturando los costos de IA al proyecto de Moneybird “Acme Website Q1–Q2” desde enero. El 1 de julio, entra en vigor un nuevo contrato de 6 meses. El proyecto de Moneybird del cliente cambia a “Acme Website Q3–Q4” — posiblemente con una tarifa por hora diferente. El repositorio y la rama son los mismos.

Lo que Anna quiere:

• A partir del 1 de julio, todos los nuevos costos de IA se sincronicen con el nuevo proyecto.
• Los seis meses de entradas de tiempo ya en Moneybird bajo el proyecto anterior se mantengan exactamente donde están.
• El costo de hoy vaya al nuevo proyecto.

El riesgo sin orientación: Anna cambia su regla de facturación y ejecuta Sincronizar Ahora. La extensión re-agrega de enero a junio, no ve entradas de tiempo para esos días bajo el nuevo proyecto y crea 180 entradas duplicadas en Moneybird, junto a las que ya existen bajo el proyecto anterior.

Cómo lo maneja Vibes to Bucks: Cuando Anna edita su regla de facturación para apuntar al nuevo proyecto, la extensión le pregunta qué debería pasar con los costos históricos. Ella elige “Aplicar desde hoy en adelante”. Los días pasados mantienen su asociación con el proyecto anterior. Solo hoy y los días futuros se sincronizan bajo el nuevo proyecto. Sin duplicados, sin necesidad de limpieza.

Escenario 2 — Cambio de cliente: mover un repositorio a un cliente diferente

Quién: Ben, un desarrollador trabajando en github.com/org/platform.

Qué pasó: Ben inicialmente facturó este repositorio al Cliente Alpha, quien financió la fase de I+D. La plataforma ahora está en producción y el Cliente Beta es el cliente actual. Ben necesita reasignar el repositorio.

2a — Corte limpio

Lo que Ben quiere: Los costos futuros van al Cliente Beta. Las entradas pasadas sincronizadas con el Cliente Alpha permanecen intactas. Nada retroactivo.

Cómo lo maneja Vibes to Bucks: Ben cambia el contacto de la regla de facturación de Alpha a Beta. La extensión pregunta qué debería pasar con el historial. Él elige “Aplicar desde hoy en adelante”. Las entradas históricas de Alpha permanecen en Moneybird. Beta comienza a recibir entradas desde hoy.

2b — Corrección retroactiva completa

Lo que Ben quiere: La facturación a Alpha fue un error — todo debería haber sido para Beta desde el principio. Ben quiere re-sincronizar todo bajo Beta. Acepta que tendrá que limpiar las entradas de Alpha manualmente en Moneybird.

Cómo lo maneja Vibes to Bucks: Ben elige “Aplicar a todo el tiempo”. La extensión le advierte que las entradas existentes bajo Alpha no se eliminarán automáticamente — tendrá que eliminarlas en Moneybird. Luego crea nuevas entradas para cada día histórico bajo Beta.

2c — Sincronizar solo la brecha

Lo que Ben quiere: Ben dejó de sincronizar hace dos semanas cuando se dio cuenta de que la asignación estaba equivocada. Tiene 14 días de costos no sincronizados en el libro mayor. Quiere que esos 14 días vayan a Beta, pero los meses ya sincronizados con Alpha deben permanecer.

Cómo lo maneja Vibes to Bucks: Ben elige “Aplicar solo a los días no sincronizados”. La extensión sabe qué días ya tienen una entrada de tiempo en provider_posts y los omite. Solo los 14 días no sincronizados se crean bajo Beta.

Escenario 3 — División de proyecto: redistribuir el trabajo entre sub-proyectos

Quién: Clara, una desarrolladora trabajando en un monorepo para el Cliente Gamma.

Qué pasó: Clara ha estado facturando todo el trabajo de IA a un proyecto general “Desarrollo General”. Gamma ahora quiere que los costos se desglosen por área de características. Clara crea reglas de facturación basadas en ramas: feature/auth/* → “Módulo de Autenticación” y feature/billing/* → “Módulo de Facturación”.

3a — División solo hacia adelante

Lo que Clara quiere: De ahora en adelante, los costos se dirigen al sub-proyecto correcto. Los costos pasados ya sincronizados bajo “Desarrollo General” permanecen allí.

Cómo lo maneja Vibes to Bucks: Cuando Clara agrega las nuevas reglas de rama, la extensión pregunta sobre el historial para cada una. Ella elige “Aplicar desde hoy en adelante” para ambas. Las entradas históricas bajo “Desarrollo General” no se tocan.

3b — Precisión histórica

Lo que Clara quiere: En realidad quiere mover retroactivamente los costos pasados a los sub-proyectos correctos. Acepta que eliminará manualmente las entradas antiguas de “Desarrollo General” en Moneybird.

Cómo lo maneja Vibes to Bucks: Clara elige “Aplicar a todo el tiempo” para las nuevas reglas. La extensión advierte sobre las entradas existentes bajo el proyecto anterior y crea entradas correctas por sub-proyecto por día. Clara limpia las entradas antiguas en Moneybird.

Escenario 4 — Trabajo de cortesía no facturable

Quién: David, un freelancer trabajando en el repositorio del Cliente Delta.

Qué pasó: David es involucrado en una revisión de código interna y algunas pruebas que no forman parte del alcance de Delta, pero mantiene Cursor abierto en su repositorio. No quiere que las próximas 2 horas de costo de IA se carguen a Delta.

Lo que David quiere:

• Cambiar la regla de facturación de Delta a modo “no facturable”. Un indicador visible en la barra de estado confirma que la regla no es facturable.
• Los costos de IA aún se rastrean y son visibles en el tablero, quiere ver cuánto le cuesta este trabajo de cortesía, pero marcados como no facturables.
• Cada hora, una notificación de recordatorio: “La regla de facturación de Delta no ha sido facturable durante 2 horas. ¿Sigues trabajando sin facturar?”
• Cuando vuelve a cambiar a facturable, la sincronización normal se reanuda.
• Los costos no facturables se muestran en el tablero bajo Delta, pero claramente distinguidos de los costos facturables.

Por qué por asignación, no global: David podría estar haciendo varias tareas a la vez. Si cambia al repositorio del Cliente Beta mientras Delta no es facturable, Beta debería seguir facturando normalmente. No facturable es una decisión de cortesía por cliente: “este costo que estoy generando no es un pedido del cliente, lo hago como cortesía para ellos”.

Cómo lo maneja Vibes to Bucks: David abre el panel de Configuración y cambia la regla de facturación de Delta a no facturable. Un diálogo pregunta dos cosas: cuándo debería comenzar el modo no facturable (ahora o retroactivamente) y cuándo debería terminar. David elige “Desde ahora” y “Fin del día” — la facturación se reanuda automáticamente mañana. La barra de estado muestra $4.23 hoy · Delta [no facturable hasta el fin del día] mientras trabaja en el repositorio de Delta. Los costos no facturables aún se sincronizan con Moneybird como entradas de tiempo no facturables (visibles en los registros pero excluidas de la facturación al cliente). El tablero muestra tanto los costos facturables como los no facturables para Delta, claramente separados.

Si David espera que el trabajo de cortesía dure más, puede elegir “Fecha específica” (por ejemplo, no facturable hasta el viernes) o “Hasta que reanude manualmente” con un intervalo de recordatorio (cada 30 minutos, 1 hora, 2 horas, etc.) para que no olvide volver a activar la facturación.

Variación — no facturable retroactivo

Lo que David quiere: Olvidó cambiar antes de comenzar. Quiere marcar los últimos 90 minutos como no facturables después del hecho.

Cómo lo maneja Vibes to Bucks: David abre el panel de Configuración, cambia Delta a no facturable, y en la sección Inicio elige “Retroactivo” con un tiempo de 90 minutos atrás. Los costos desde ese punto en adelante se marcan como no facturables. Si la entrada de tiempo de hoy ya se sincronizó con Moneybird, la extensión recalcula y la actualiza para reflejar la cantidad facturable reducida. La retroactividad está limitada a hoy — para correcciones de varios días, el Libro Mayor de Sincronización proporciona controles de deshacer y re-sincronización.

Escenario 5 — Deshacer una sincronización incorrecta

Quién: Eve, una freelancer que cambió una asignación y ejecutó Sincronizar Ahora inmediatamente.

Qué pasó: Eve editó una regla de facturación (cambió el proyecto) y ejecutó Sincronizar Ahora sin pensar en las consecuencias. La extensión creó 3 meses de nuevas entradas de tiempo bajo el proyecto incorrecto en Moneybird, junto a las entradas correctas existentes bajo el proyecto anterior.

Lo que Eve quiere:

• Ver lo que se acaba de sincronizar — un resumen que muestre cuántas entradas se crearon o actualizaron, para qué días, bajo qué proyecto.
• Deshacer: ya sea que la extensión elimine las entradas creadas incorrectamente, o que le diga claramente qué IDs de entrada limpiar manualmente.

Cómo lo maneja Vibes to Bucks: Después de cada sincronización, la extensión muestra una notificación: “Sincronizado con Moneybird — Creado 87, actualizado 2, omitido 14.” Al hacer clic en “Mostrar detalles” se abre el Libro Mayor de Sincronización — una vista dedicada que muestra cada entrada sincronizada y pendiente, filtrable por cliente, proyecto y fecha. Eve puede ver exactamente qué entradas se acaban de crear, seleccionar las incorrectas y hacer clic en “Deshacer sincronización.” La extensión elimina esas entradas de Moneybird y las marca como pendientes nuevamente para que puedan re-sincronizarse correctamente después de que ella corrija la regla.

Escenario 6 — Facturación temporal de proyectos

Quién: Frank, un desarrollador trabajando en github.com/acme/api.

Qué pasó: Frank normalmente factura al proyecto “Mantenimiento de API”. Durante dos semanas en marzo, está en un sprint especial facturado a “Migración de API v2”. Después del sprint, vuelve a cambiar.

Lo que Frank quiere:

• Cambiar la regla de facturación a “Migración de API v2” el 10 de marzo.
• Cambiarla de nuevo a “Mantenimiento de API” el 24 de marzo.
• Solo la ventana del 10 al 23 de marzo se sincroniza con “Migración de API v2”.
• Todo antes del 10 de marzo y después del 23 de marzo se sincroniza con “Mantenimiento de API”.
• Sin desorden retroactivo en ninguna dirección.

Cómo lo maneja Vibes to Bucks: Ambas veces que Frank cambia la regla de facturación, elige “Aplicar desde hoy en adelante”. El 10 de marzo, la regla comienza a facturar a “Migración de API v2”. El 24 de marzo, cambia de nuevo a “Mantenimiento de API”. Las entradas de cada período permanecen con el proyecto que estaba activo en ese momento.

Escenario 7 — Dejar de facturar, seguir rastreando

Quién: Gina, una freelancer que está terminando con el Cliente Eta.

Qué pasó: El contrato ha terminado, pero Gina todavía hace mantenimiento menor en el repositorio de Eta. Quiere ver los costos de IA en su tablero — para evaluar si un nuevo contrato valdría la pena — pero no quiere sincronizar ninguna entrada de tiempo.

Lo que Gina quiere:

• Marcar la regla de facturación como permanentemente no facturable (no un cambio temporal — una configuración duradera).
• El tablero sigue mostrando costos atribuidos al Cliente Eta.
• La sincronización omite esta regla de facturación por completo.
• Si Eta regresa con un nuevo contrato, cambia de nuevo a facturable y solo sincroniza desde ese punto en adelante — no el período de brecha.

Cómo lo maneja Vibes to Bucks: Gina desmarca “Facturable” en la regla de facturación de Eta. Los costos continúan siendo rastreados y aparecen en el tablero bajo Eta, pero no se crean entradas de tiempo. Cuando llega un nuevo contrato, vuelve a habilitar la facturación y elige “Aplicar desde hoy en adelante”. La brecha no facturable permanece sin facturar.

Escenario 8 — Migración de proveedor

Quién: Hugo, un freelancer que ha estado sincronizando con Moneybird durante 6 meses.

Qué pasó: La firma contable de Hugo lo cambia a Harvest. Cambia destination: harvest en su configuración y configura nuevas reglas de facturación de Harvest.

Lo que Hugo quiere:

• De ahora en adelante, la sincronización va a Harvest.
• Los 6 meses de entradas de Moneybird permanecen intactos.
• No se crean entradas retroactivas en Harvest para el período histórico.

Cómo lo maneja Vibes to Bucks: Cuando Hugo cambia el proveedor de facturación, la extensión detecta que Harvest no tiene historial de sincronización. Sin orientación, intentaría crear entradas para cada día histórico. En su lugar, aparece el mismo diálogo de tres opciones: “Comenzar desde hoy”, “Sincronizar todo el historial”, o “Sincronizar solo los días no sincronizados.” Hugo elige “Comenzar desde hoy.” La extensión establece una fecha de corte de migración para que el motor de sincronización omita todos los días anteriores a hoy. Solo hoy y los días futuros crean entradas en Harvest. Sus entradas de Moneybird permanecen intactas.

Escenario 9 — Eliminación accidental de regla

Quién: Ivan, un freelancer que factura el repositorio del Cliente Kappa.

Qué pasó: Ivan quería editar su regla de facturación para cambiar la tarifa por hora, pero accidentalmente la eliminó en su lugar. Se da cuenta de inmediato y recrea la regla con la configuración correcta.

Lo que Ivan quiere:

• Recrear la regla sin causar meses de entradas de tiempo duplicadas en Moneybird.
• Las entradas pasadas que ya fueron sincronizadas deben permanecer intactas.
• La facturación debe continuar sin problemas como si nada hubiera pasado.

El riesgo sin orientación: Ivan crea la nueva regla. La extensión ve un repositorio con datos de costos históricos y sin historial de regla de facturación coincidente. Una sincronización ingenua trataría cada día pasado como “nunca sincronizado bajo esta regla” y crearía entradas para toda la historia.

Cómo lo maneja Vibes to Bucks: Cuando Ivan crea una regla de facturación para un repositorio que ya tiene datos de costos históricos en el libro mayor, la extensión lo reconoce y presenta el mismo diálogo de tres opciones. Ivan elige “Aplicar desde hoy en adelante” — las entradas pasadas permanecen como estaban, y la facturación se reanuda desde hoy. Sin duplicados, sin brechas, sin pánico.

El hilo común

Cada escenario anterior se reduce a una pregunta: cuando cambias una regla de facturación, ¿qué debería pasar con el pasado?

Vibes to Bucks nunca toma esa decisión por ti. Cada vez que editas una regla de facturación — cambias el cliente, proyecto, tarifa o estado de facturación — la extensión te pide que elijas:

Esta elección guiada aparece en un diálogo claro cada vez que un cambio en la regla de facturación podría afectar cómo se manejan los costos históricos. Sin sorpresas, sin re-facturación retroactiva silenciosa, sin duplicados huérfanos.