Administración de la edición musical explicada: funciones, flujos de trabajo y estándares para la gestión de derechos

La administración de la edición musical explicada es una referencia técnica compacta que traza las funciones, las transferencias operativas y los estándares de la industria que rigen la gestión de derechos en la edición musical. Presenta flujos de trabajo integrales y los formatos de archivo e identificadores exactos que debe utilizar: DDEX ERN/RIN, CWR, ISWC, ISRC, IPI, GRid, y destaca dónde suelen producirse las discrepancias y las fugas. Los ingenieros, los gestores de derechos y los investigadores encontrarán patrones de integración concretos, indicadores clave de rendimiento (KPI) y listas de comprobación para reducir los ingresos no coincidentes, acortar los ciclos de conciliación y crear sistemas auditables.

1. Ecosistema de la administración de la edición musical y principales interesados

Aserción principal: los metadatos y los identificadores son la moneda de cambio real en la administración de la edición musical; el ecosistema es un conjunto de transferencias basadas en funciones que intercambian esos activos, no una única cadena lineal.

Principales interesados y productos primarios

Lo que cada interesado espera a cambio: los editores musicales esperan informes de uso y pagos precisos; las sociedades esperan CWR o cargas útiles específicas de la sociedad e identificadores validados; los DSP esperan GRid/ISRC y metadatos de lanzamiento limpios. Cuando esas expectativas no coinciden, la conciliación se convierte en trabajo manual y la latencia de los pagos aumenta.

• Transferencia de editor musical a subeditor: el editor musical local envía las divisiones autorizadas y el ISWC; el subeditor los adapta a las normas de registro locales y puede fragmentar la cadencia de los informes, lo que aumenta los puntos de conciliación.
• Transferencia de distribuidor a editor musical: los distribuidores entregan un DDEX ERN/RIN con GRid e ISRC; si el ERN carece de un ISWC o una división canónica, el editor musical debe enriquecerlo antes del registro en una PRO, lo que provoca retrasos.
• Informes de uso de DSP a PRO/CMO: los DSP suministran registros de reproducción; las sociedades hacen coincidir los identificadores y los metadatos. Los títulos no coincidentes o la falta de IPI son el modo de fallo más común y activan las colas de excepción.

Compromiso práctico: centralice su repertorio canónico en un único sistema y reducirá las disputas y el tiempo de coincidencia, pero introducirá un cuello de botella de gobernanza y un único punto de fallo de actualización. Delegar en los subeditores acelera la concesión de licencias locales, pero multiplica las fuentes canónicas y aumenta el trabajo de conciliación.

Ejemplo concreto: un editor musical independiente entregó un lanzamiento a un distribuidor con GRid e ISRC, pero sin ISWC. El DSP informó de millones de reproducciones; la PRO no pudo hacer coincidir los ingresos de la composición porque la obra no se había registrado con un ISWC. Para resolverlo, fue necesario confirmar manualmente la división, volver a enviar un CWR a la PRO y retener las distribuciones durante tres semanas.

Si desea conocer los detalles técnicos de los formatos de mensaje utilizados en estas transferencias, consulte las especificaciones de DDEX y la guía de la CISAC sobre el manejo del repertorio en CISAC.

Siguiente consideración: asigne estos interesados a los sistemas y colas que ya ejecuta y decida quién será el propietario del enriquecimiento canónico para cada identificador antes de empezar a automatizar las fuentes.

2. Funciones y responsabilidades en detalle

La responsabilidad directa importa más que los títulos. Para la fiabilidad operativa, debe indicar quién posee los ID canónicos, quién valida las divisiones y quién es responsable cuando una fuente no supera la conciliación; a continuación, incorpore esas responsabilidades en las comprobaciones de procesos y sistemas.

Funciones del lado del editor musical y lo que realmente hacen

• Gestor de licencias: negocia y firma licencias, emite condiciones comerciales y confirma las obligaciones territoriales y de uso que los sistemas posteriores deben hacer cumplir.
• Gestor de repertorio: posee los registros canónicos de obras/grabaciones, solicita la emisión de ISWC/ISRC y posee la única fuente de verdad para las divisiones y la procedencia.
• Gestor de metadatos: aplica las normas de esquema para GRid/ISRC/ISWC, ejecuta el enriquecimiento (por ejemplo, MusicBrainz) y aprueba las cargas útiles de ERN antes de la distribución.
• Analista de derechos: resuelve los casos límite de propiedad, audita las discrepancias de división y traduce las cláusulas contractuales en normas del sistema para los motores de coincidencia.
• Contable de regalías: define los periodos contables, valida las declaraciones de la sociedad y ejecuta el motor de distribución con normas documentadas de redondeo y recuperación.
• Enlace con el subeditor: adapta los datos del editor musical local a los requisitos de la sociedad local y mantiene los SLA de conciliación con los socios territoriales.

Responsabilidades de la sociedad, el cobro y el desarrollador

Las sociedades y las CMO operan como guardianes: los equipos de ingestión validan las cargas útiles de CWR o de la API de la sociedad, los equipos de coincidencia realizan la atribución con respecto a su repertorio y las operaciones de pago ejecutan las distribuciones según los calendarios específicos de la sociedad. Espere variaciones en los formatos aceptados y los criterios de aceptación; consulte los documentos de cada sociedad (por ejemplo, las especificaciones de DDEX y las páginas técnicas de la sociedad).

• Ingeniero de datos: crea canales de ingestión con validación de esquemas, enriquecimiento y procesamiento idempotente.
• Ingeniero de integración/propietario de la API: implementa reintentos, claves de idempotencia y SLA para las fuentes ascendentes y las API de la sociedad.
• Propietario del motor de coincidencia: ajusta los umbrales para equilibrar los falsos positivos con el volumen de excepciones manuales y documenta las normas de coincidencia.
• Ingeniero de calidad/responsable de la conciliación: posee las colas de excepciones diarias y produce pistas listas para la auditoría para las disputas.

Compromiso práctico: centralice el repertorio canónico para reducir las tasas de no coincidencia, pero acepte un coste de gobernanza: cada cambio necesita procesos de escritura controlados, registros de cambios y reversión. Los modelos federados reducen los cuellos de botella, pero aumentan el trabajo de conciliación y requieren normas de normalización más estrictas.

Ejemplo concreto: un editor musical independiente de tamaño medio delegó las actualizaciones de metadatos a los distribuidores. Un nuevo lanzamiento carecía del ISWC y tenía variantes inconsistentes del nombre del compositor. Cuando los DSP informaron del uso, la PRO rechazó las coincidencias; el editor musical necesitó una nueva presentación de CWR y una confirmación manual de la división, lo que retrasó los pagos al compositor en un ciclo de liquidación y generó tres días de procesamiento de excepciones.

Criterio: la automatización corrige la escala, pero nunca sustituye a un pequeño equipo que entienda el texto del contrato. Invierta pronto en una función de analista de derechos; reduce los ciclos de disputa más que añadir otra norma de coincidencia en el código. Para obtener detalles sobre la implementación, consulte nuestro recorrido técnico por la ingestión de DDEX ERN en la guía DDEX ERN explicada.

Decida quién posee los ID canónicos, codifique su autoridad en los SLA y los esquemas, e instrumente esa propiedad con registros de auditoría; esta única decisión reduce el trabajo de conciliación repetido más que cualquier ajuste del algoritmo de coincidencia.

3. Flujos de trabajo integrales: del registro a la distribución

Punto directo: un flujo de trabajo operativo debe tratarse como una serie de transferencias protegidas, no como una transferencia de archivos de una sola pasada. Cada etapa (ingestión, enriquecimiento, registro, notificación, coincidencia, conciliación, distribución) crea un estado del que dependen los sistemas posteriores, por lo que debe diseñarse para eventos inmutables, control de versiones y una propiedad clara en cada transferencia.

Secuencia de pasos canónica y estándares aplicados

• Validación previa al lanzamiento: el distribuidor produce un DDEX ERN/RIN que contiene GRid e ISRC; ejecute comprobaciones de esquema y validación de la presencia de identificadores antes de la carga a los DSP para evitar excepciones posteriores.
• Enriquecimiento y canonización: añada los identificadores que faltan (ISWC, IPI) y normalice los nombres de los colaboradores en un canal controlado; almacene el enriquecimiento como un evento de cambio auditable en lugar de sobrescribir la carga útil original.
• Registro de obra: envíe CWR o cargas útiles de la API específicas de la sociedad a las PRO/CMO una vez que los metadatos canónicos sean estables; incluya divisiones autorizadas y campos de procedencia para que las sociedades puedan aceptar coincidencias automatizadas.
• Notificación e ingestión de uso: los DSP y las plataformas entregan registros de uso (RIN o extractos específicos de la plataforma); normalice las marcas de tiempo, los territorios y los contextos de reproducción antes de la coincidencia.
• Coincidencia y atribución: prefiera las coincidencias de identificador primero (ISWC/ISRC/IPI) con un paso de título difuso de reserva; mantenga una puntuación de coincidencia clasificada y un registro de auditoría inmutable para cada decisión de atribución.
• Conciliaciones y liquidaciones: concilie las declaraciones de la sociedad con las ejecuciones internas y dirija las excepciones a una cola humana con normas de priorización; emita instrucciones de distribución al motor de pago solo después de que se cierre la conciliación.

Compromiso práctico: el procesamiento por lotes reduce el tráfico de la API y simplifica la idempotencia, pero aumenta la latencia y empeora el flujo de caja para los creadores. Los canales casi en tiempo real reducen el tiempo de pago, pero requieren una validación más sólida, más cálculo y una semántica de reintento robusta.

Limitación operativa que debe planificar: los cambios de división después del registro crean dolores de cabeza con el control de versiones. Si sobrescribe las divisiones en su lugar, corre el riesgo de realizar pagos dobles o reclamaciones huérfanas. En su lugar, implemente las modificaciones de división como deltas con fechas de entrada en vigor y genere deltas de conciliación para cada ejecución de liquidación.

Ejemplo concreto: un editor musical de tamaño medio aceptó lanzamientos de un distribuidor en los que las grabaciones llevaban GRid/ISRC, pero no ISWC. Después de que llegaran los informes de los DSP, el editor musical ejecutó un trabajo de enriquecimiento que hacía coincidir las grabaciones con las obras, emitió registros de CWR a PRS y GEMA, y luego concilió las declaraciones de la PRO entrantes con las ejecuciones de regalías internas. El proceso requirió tres tipos de mensajes coordinados (DDEX ERN, CWR, declaración de uso de la sociedad) y una semana de gestión de excepciones antes de que pudieran continuar las distribuciones.

Criterio práctico: confiar en la coincidencia de títulos difusos como estrategia principal es una falsa economía. Mantiene los volúmenes de excepciones engañosamente bajos solo hasta que llega un gran catálogo o una fuente multiterritorial. Invierta pronto en la higiene de los identificadores, los canales de enriquecimiento y un pequeño equipo de analistas de derechos para eliminar las excepciones complejas; esta combinación reduce la carga manual a largo plazo más que el ajuste incremental de las normas de coincidencia.

Punto de control que debe aplicarse: exija la validación de la carga útil de ERN/RIN y la finalización del enriquecimiento antes de permitir cualquier liquidación basada en el uso para ese lanzamiento.

4. Estándares, identificadores y formatos de archivo explicados

Punto directo: el uso coherente de los identificadores en los lanzamientos, las obras y las partes es la palanca práctica que reduce las discrepancias con mayor eficacia; los formatos de archivo y los esquemas solo importan si los identificadores están presentes y son precisos.

Identificadores: qué llevar, cuándo y qué puede fallar

Trate cada identificador como un índice en la lógica operativa. ISRC se vincula a una grabación de sonido específica y es obligatorio para la coincidencia a nivel de grabación. ISWC se vincula a la composición y es lo que la mayoría de las PRO utilizan para la atribución de obras. IPI (parte interesada) e ISNI identifican a los colaboradores y las organizaciones para el enrutamiento de la propiedad y los pagos. GRid agrupa los lanzamientos y simplifica la conciliación a nivel de lanzamiento. La falta de identificadores de parte o la ambigüedad de los mismos crean la mayoría de las excepciones manuales porque las sociedades asignan el dinero a las partes, no a los nombres de archivo.

Formatos de archivo y dónde encajan en los sistemas reales

Los formatos se dividen en dos categorías prácticas: esquemas de la industria para el intercambio entre organizaciones y cargas útiles ligeras para los canales internos o los informes ad hoc. Utilice los primeros para las transferencias de máquina a máquina con las sociedades y los DSP; utilice los segundos solo después del enriquecimiento y la validación.

• DDEX ERN/RIN: mensajería de lanzamiento y grabación de distribuidores a DSP y editores musicales; lleva GRid, ISRC, funciones de colaborador y estructura de lanzamiento. Consulte las especificaciones de DDEX.
• CWR: formato de registro de obra que la mayoría de las PRO siguen aceptando; autorizado para muchas sociedades al registrar divisiones y propiedad.
• API de la sociedad/JSON: se está volviendo común para los registros y las extracciones de declaraciones; varían ampliamente en los campos obligatorios y las normas de validación.
• Fuentes ad hoc CSV/JSON: útiles para la conciliación interna o cuando un socio no puede producir DDEX/CWR; requieren contratos de esquema estrictos para evitar la ambigüedad.

Compromiso que debe planificar: la conversión de un DDEX ERN enriquecido en CWR a menudo pierde la procedencia (quién fue el autor de un cambio de división y cuándo). Esa pérdida complica las disputas. Si debe convertir, conserve la carga útil original de ERN como un registro inmutable e incluya una tabla de asignación que registre la procedencia y las marcas de tiempo a nivel de campo.

Ejemplo concreto: un subeditor envió un ERN con los colaboradores solo por su nombre. Durante la conversión automática a CWR, los campos IPI estaban en blanco, por lo que la PRO receptora rechazó el registro. El editor musical tuvo que obtener los IPI que faltaban, volver a enviar el CWR y registrar tres eventos de cambio separados para conciliar el historial de divisiones entre los sistemas. Ese proceso añadió dos ciclos de conciliación y requirió la intervención manual de un analista de derechos.

Criterio: dedique tiempo de desarrollador a aplicar la validación de identificadores y la retención de cargas útiles originales antes de invertir en actualizaciones de esquemas. En la práctica, la higiene de los identificadores y los registros de procedencia inmutables reducen el volumen de disputas más que el soporte de la versión de esquema más reciente.

5. Sistemas, patrones de integración y middleware

Punto directo: la integración tiene éxito cuando se separa el modelo de repertorio canónico de los conectores perimetrales que hablan con los DSP, las sociedades y los agregadores. Trate el sistema canónico como la única fuente de verdad para los identificadores, las divisiones y la procedencia, y cree adaptadores transitorios a su alrededor en lugar de intentar que cada socio externo acepte su modelo interno.

Patrones arquitectónicos que realmente funcionan

• Centro canónico con adaptadores: mantenga una única base de datos de repertorio canónico y exponga traductores finos por socio. Esto reduce los puntos de conciliación porque las conversiones se producen en rutas de código controladas, no en hojas de cálculo ad hoc.
• Canal de enriquecimiento de origen de eventos: publique cada cambio (nuevo ISWC, modificación de división) como un evento inmutable. Los consumidores (motor de coincidencia, ejecución de regalías, adaptadores de la sociedad) reproducen los eventos para mantenerse sincronizados y crear deltas de conciliación deterministas.
• Captura de datos de cambio (CDC) + bus de mensajes: utilice CDC desde su base de datos canónica en un flujo de mensajes (Kafka, Pulsar) para entregar actualizaciones incrementales con garantías de ordenación; evita el reprocesamiento de archivos completos y simplifica la idempotencia.
• Híbrido de lote para la liquidación, flujo para las alertas: ejecute trabajos por lotes nocturnos para la liquidación final y utilice el flujo para la detección de excepciones en tiempo real y las distribuciones de pequeño valor para mejorar el flujo de caja del creador sin que explote la complejidad del sistema.

Responsabilidades del middleware y compromisos prácticos

Lo que el middleware debe garantizar: validación de esquemas, transformaciones deterministas, entrega idempotente y un registro de auditoría consultable que vincule las cargas útiles entrantes originales con los artefactos posteriores. Si el middleware falla en alguno de estos puntos, la conciliación se vuelve manual muy rápidamente.

Compromiso que debe aceptar: los adaptadores ligeros sin servidor se escalan de forma económica para los socios ocasionales, pero aumentan la superficie operativa para muchos conectores pequeños. Un ESB o una plataforma de adaptadores centralizada es más costosa al principio, pero reduce el mantenimiento a largo plazo cuando se integran docenas de sociedades y DSP.

Limitación que debe planificar: el middleware puede normalizar los metadatos, pero no puede inventar identificadores autorizados. Espere flujos de trabajo humanos continuos para los IPI/ISWC que faltan; la automatización reduce el volumen, no la necesidad de una revisión experta.

Controles operativos, SLA y patrones de desarrollador

• Pruebas de contrato primero con el esquema: publique contratos legibles por máquina (OpenAPI/JSON Schema) para cada adaptador y ejecute pruebas de contrato de CI contra los entornos de pruebas de los socios para detectar los cambios importantes de forma temprana.
• Idempotencia y puntos de control del consumidor: cada fuente entrante debe incluir una clave de idempotencia; los consumidores escriben un punto de control después de un procesamiento exitoso para evitar duplicados durante los reintentos.
• Transformaciones versionadas y procedencia: almacene las cargas útiles originales de forma inmutable y registre las versiones de transformación para que las disputas puedan resolverse con la entrada exacta utilizada para generar un registro o un pago.
• Sugerencias de SLA: procure la validación del esquema en el plazo de 1 hora posterior a la ingestión, el enriquecimiento en el plazo de 24 horas para los nuevos lanzamientos y el cierre de la conciliación en el plazo de un ciclo de liquidación. Ajuste en función del tamaño y los territorios de sus editores musicales.

Ejemplo concreto: un editor musical implementó CDC desde su base de datos de repertorio en Kafka. Un microservicio de enriquecimiento se suscribió al flujo, añadió referencias de ISWC e IPI consultando MusicBrainz y las tablas de búsqueda internas, y emitió cargas útiles normalizadas de CWR y DDEX a servicios de adaptadores separados. Los adaptadores de la sociedad tradujeron los objetos normalizados en API específicas de la sociedad, mientras que el motor de regalías consumió el mismo flujo normalizado para las ejecuciones de distribución, manteniendo los deltas de conciliación pequeños y auditables.

Información operativa: cree un middleware para que las discrepancias sean baratas de detectar y caras de ignorar. Las alertas rápidas y las pequeñas colas dirigidas por humanos se escalan mejor que las grandes ejecuciones de conciliación manual enterradas en los ciclos contables.

Para obtener orientación sobre la implementación y notas sobre el esquema, consulte las especificaciones de DDEX y nuestro recorrido técnico por la ingestión de DDEX en DDEX ERN explicado.

6. Ejemplos del mundo real y casos prácticos de modos de fallo comunes

Respuesta directa: la mayoría de los fallos operativos se remontan a tres cosas: la ambigüedad de los identificadores, las discrepancias de tiempo/versión y la falta de coincidencia de la semántica comercial entre los territorios. Esas causas fundamentales producen los síntomas recurrentes que ya conoce: altas tasas de no coincidencia, pagos dobles y largas colas de excepciones. Las correcciones son tanto de procedimiento como técnicas.

Caso práctico: reutilización de ISRC y colisiones de GRid. Un sello discografico heredado resurgió grabaciones que reutilizaban los ISRC de un catálogo de 2005. La lógica de deduplicación de los DSP y los motores de coincidencia posteriores atribuyeron nuevas reproducciones al antiguo lanzamiento; los pagos se dirigieron a los titulares de derechos anteriores. La solución requirió extraer las cargas útiles originales de DDEX ERN, consultar los manifiestos del distribuidor y añadir normas de desambiguación de fecha de lanzamiento + GRid al motor de coincidencia. La lección práctica: nunca trate un único campo de identificador como garante de la singularidad sin claves contextuales (fecha de lanzamiento, GRid) y procedencia.

Caso práctico: las modificaciones de la división posteriores a la liquidación crean pagos dobles. Un cambio de compositor produjo una división modificada con una fecha de entrada en vigor anterior a la última liquidación. El editor musical sobrescribió la división maestra y el motor de regalías volvió a ejecutar las distribuciones, produciendo pagos duplicados por las mismas reproducciones. Un patrón más seguro es registrar las modificaciones de la división como deltas con rangos efectivos y forzar los deltas de conciliación contra las ejecuciones de liquidación cerradas en lugar de la mutación en el lugar.

Caso práctico: discrepancias en las declaraciones de la MLC y asignación de categorías. Los editores musicales concilian con frecuencia los CSV de la MLC que dividen las ganancias en depósitos estatutarios que no coinciden con las líneas contables internas. Un editor musical de tamaño medio asumió tasas mecanicas por reproducción y marcó grandes variaciones; la causa real eran las diferentes categorías de facturación y los pequeños ajustes no asignados en la declaración de la MLC. En la práctica, debe ingerir las cargas útiles sin procesar de la MLC, asignar las categorías de la MLC a los libros mayores de ingresos internos y conservar la carga útil original para la auditoría. Consulte el centro de conocimiento de la MLC para conocer los formatos de declaración que encontrará.

Caso práctico: deriva de la codificación y el esquema en las fuentes CSV ad hoc. Un subeditor envió los créditos del compositor como un CSV delimitado por punto y coma en Windows-1252. El canal de ingestión esperaba archivos UTF-8 delimitados por comas, produjo filas de colaboradores mal analizadas e hizo coincidir los créditos con los IPI incorrectos. La solución combinó una validación de esquemas más estricta, la detección automatizada del orden de bytes/codificación y un arnés de prueba de socios en espacio aislado para rechazar los archivos no conformes antes de que lleguen al repertorio canónico.

Compromisos prácticos y criterio. Puede automatizar mucho, pero la automatización amplifica los datos de origen incorrectos. Priorice tres inversiones que den sus frutos: un enriquecimiento robusto para suministrar los ISWC/IPI que faltan, el almacenamiento inmutable de las cargas útiles entrantes originales para la conciliación forense y el manejo de divisiones/versiones basado en deltas. Estos controles son más baratos que la dotación repetida de personal en las colas de excepciones.

7. Métricas operativas, controles y gobernanza

Aserción principal: las métricas y la gobernanza son las palancas operativas que convierten los metadatos ordenados en regalías pagadas. Realice un seguimiento de las señales correctas, aplique algunas puertas duras y reducirá las colas de excepciones y el esfuerzo forense; ignórelas y la conciliación se convertirá en una lucha reactiva contra el fuego.

Métricas principales para supervisar

Tasa de coincidencia (primero el identificador): mida el porcentaje de uso entrante que coincide con ISWC/ISRC/IPI antes de cualquier lógica difusa. Esta es la mejor señal de higiene ascendente y debe ser su KPI principal para la salud del canal.

Tiempo hasta la primera coincidencia: realice un seguimiento del tiempo transcurrido desde la ingestión hasta una coincidencia autorizada. Las colas largas aquí significan cuellos de botella de enriquecimiento o registro; las colas cortas indican un canal saludable y un flujo de caja más rápido para los creadores.

Cartera de excepciones y tiempo de resolución: cuente las excepciones abiertas y el tiempo medio para cerrar. Priorice aquellas que bloquean las liquidaciones (divisiones faltantes, ISWC faltante) sobre las discrepancias estéticas.

Cobertura de identificadores: porcentaje de actividad que lleva ISWC, ISRC e IPI válidos. La cobertura es una restricción operativa: mejorarla reduce el trabajo manual más que afinar la heurística de coincidencia.

Varianza de la conciliación y latencia de los pagos: mida la varianza en dólares entre las declaraciones de la sociedad esperadas y las reales y el tiempo desde la recepción de la declaración hasta la distribución del editor musical. Estas dos métricas capturan las fugas y la eficiencia operativa.

Controles y diseño de procesos que funcionan en la práctica

Puerta de enlace de divisiones autorizadas: exija un registro de división firmado inmutable o un delta interno aprobado antes de aceptar la actividad para la liquidación. Permitir ediciones de división en vuelo o sin versión es el camino más común hacia los pagos dobles.

Automatice pronto, revise humanamente más tarde: utilice la validación de esquemas y las comprobaciones de identificadores en la ingestión para rechazar las cargas útiles incorrectas, pero mantenga una pequeña cola humana para los casos límite de propiedad complejos que la automatización no puede resolver de forma fiable.

Clasificación de excepciones y SLA: clasifique las excepciones por impacto comercial y adjunte SLA. Las discrepancias de bajo valor se pueden procesar por lotes semanalmente; las excepciones que bloquean los pagos deben tener un SLA más corto y una escalada directa a un analista de derechos.

Procedencia y control de versiones: conserve las cargas útiles originales de ERN/CWR y registre cada transformación con un ID de versión. Si llega una disputa meses después, debe poder mostrar la entrada exacta utilizada para generar un registro o un pago.