Manejo de múltiples monedas en GnuCash

Question

Comencé a usar GnuCash cuando vivía en Alemania y por lo tanto tengo toda una estructura en euros en mi base de datos (Aktiva, Anfangszustand, Aufwendungen, Erträge, Fremdkapital).

Más tarde, me mudé a los Estados Unidos. Creé una nueva base de datos de GnuCash para eso (US Assets, US Equity, US Expenses, US Income, US Liabilities). Sin embargo, pronto descubrí que esto no era óptimo porque compraría cosas para los Estados Unidos con mis cuentas en euros y viceversa. Después de un par de meses, fusioné mis dos archivos y desde entonces tengo jerarquías tanto en los Estados Unidos como en euros y siento que es un lío.

Mi pregunta es: ¿Cuál es la forma recomendada de organizar la jerarquía?

¿Suena bien tener ambos en paralelo? ¿O sería mejor tener un contenedor común de "Assets", "Expenses", "Income", "Liabilities" y "Equity" y mover todas las cuentas debajo de él? ¿Debería usar euros o dólares estadounidenses para la cuenta de nivel superior?

De alguna manera, encuentro que el segundo enfoque es atractivo, pero no estoy seguro de si es lo correcto.

Finalmente, debido a los viajes, tengo algunos activos en otras monedas que rastreo con GnuCash. Actualmente los tengo bajo "Aktiva" (que es en euros) como "Cash (AUD)", "Cash (Swiss)", "Cash (Turkey)" etc. Pero esto me parece aleatorio. ¿Cuál es la forma adecuada de organizar esto?

Answer 1

Utilice su país de residencia actual como primario:

Resumimos los puntos principales del método SSAP 20:

Siempre hay una moneda de referencia especial, típicamente "la moneda local de la empresa". Todas las cuentas se mantienen en la moneda de referencia. Las cuentas en monedas no de referencia son sólo informativas, y no participan en el balance. Las fluctuaciones en los valores relativos de las monedas no de referencia se reflejan inmediatamente en sus cuentas de activos correspondientes (y también en una cuenta de ganancias/pérdidas de la moneda).

Las ventajas de este método son: Dado que todas las entradas están en una sola moneda, no se necesita soporte de software especial para múltiples monedas, en principio, solo se requiere software de contabilidad de una sola moneda. Las cuentas están equilibradas.

Las desventajas son: Se deben mantener "tallies" separados de las monedas extranjeras y sus tasas de cambio (las columnas verdes en los ejemplos). De hecho, estos "tallies" contienen información original (fuente), mientras que las cuentas de activos/pasivos correspondientes contienen información derivada (calculada). En cierto sentido, las cuentas en moneda extranjera que se mantienen en una moneda local son solo cuentas "virtuales", cuyos contenidos son completamente calculados. Las cuentas deben revaluarse periódicamente, y surge la pregunta de cuándo hacer esto. En principio, esto debería suceder justo antes de cada transacción y justo antes de generar un informe. Si hay muchas cuentas en moneda extranjera, esto puede significar mucho trabajo (manual). Es relativamente difícil agregar o cambiar una transacción retrospectivamente. Si se ingresa una nueva transacción para una fecha anterior, entonces todos los futuros ganancias y pérdidas de la moneda deben calcularse nuevamente. Esto cambia las transacciones futuras, no solo los saldos futuros. Existe una asimetría insatisfactoria en este método contable, porque una moneda debe darse prominencia sobre todas las demás.

Las tres primeras de estas desventajas pueden aliviarse utilizando un software que admita el método contable SSAP 20. En este caso, el usuario solo tiene que ingresar los datos de las columnas verdes, y el software se encarga de las conversiones, revaluaciones y cálculos de las ganancias y pérdidas correspondientes.

Luego use el editor de precios para cada cuenta extranjera:

Referencias

• Peter Selinger: Tutorial sobre contabilidad de múltiples monedas

• GnuCash: Stock and Currencies – Blog de Flameeyes

• Documentos de GnuCash: Capítulo 12. Múltiples Monedas