50 declaraciones de transacción coreanas,
Una hoja de cálculo: por lotes sin teclear
Cualquier ERP coreano puede generar una declaración de transacción (거래명세서) a partir de un registro de ventas con un clic. Ninguno puede leerla de vuelta. El documento que acompaña cada envío físico entre empresas coreanas —con nombres de artículos, cantidades, precios unitarios y valores de suministro— entra en su flujo de compras a través del teclado, campo por campo. Cuando recibe cincuenta de ellos de quince proveedores a fin de mes, esa asimetría deja de ser una curiosidad y se convierte en la razón por la que su equipo de recepción sigue en la oficina a las 10 de la noche.
Puntos clave
- Cualquier ERP coreano puede generar una 거래명세서 a partir de un registro de ventas con un clic, y precisamente ninguno puede leerla de vuelta, por eso su equipo de recepción sigue tecleando a las 10 de la noche.
- Cincuenta 거래명세서 de quince proveedores requieren 5,5 horas de entrada manual, pero el verdadero problema no es su velocidad al teclear, sino que la industria pasó décadas perfeccionando la automatización de salida y dejó la extracción de entrada a su teclado.
- ImageToTable.ai procesa los cincuenta documentos con una sola definición de columna —sin plantillas por proveedor, sin bucle de revisión por documento— y entrega una única hoja de cálculo donde cada línea se remonta a su archivo de origen.
Si es nuevo en las declaraciones de transacción coreanas, comience con nuestra guía para extraer datos de declaraciones de transacción coreanas a Excel, que cubre la estructura de campos, la conciliación a 3 bandas y el problema del fallo de plantillas. Este artículo se centra en lo que cambia cuando pasa de un documento a cincuenta, del formato de un proveedor a quince.
Qué significa realmente el procesamiento por lotes para las compras coreanas
La diferencia entre procesar una declaración de transacción (거래명세서) y cincuenta no es solo cuestión de tiempo. Se trata de una clase de problema completamente distinta.
Procese una sola 거래명세서 — un proveedor, un envío, un documento — y su flujo de trabajo es sencillo. Abra el PDF. Lea el nombre del proveedor (공급자), la fecha de transacción (거래일자), la tabla de artículos. Escriba el nombre del artículo (품목명), la cantidad (수량), el precio unitario (단가) y el importe de la línea (금액) de cada fila en su hoja de cálculo de recepción. Copie el valor del suministro (공급가액) y el importe del IVA (세액) en su archivo de conciliación. Listo. Tres minutos por documento, quizá cinco si el diseño del proveedor es denso o la calidad del escaneo es deficiente.
Ahora hágalo cincuenta veces — de quince proveedores diferentes, cada uno con su propio diseño, su propio sistema de códigos de artículo, su propia calidad de impresión. Los problemas que surgen a escala son invisibles en el procesamiento de un solo documento:
- Recorrido de formatos. La 거래명세서 del proveedor A es un PDF nítido generado por Douzone iCUBE, con la tabla de artículos en un diseño de cuadrícula estándar. La del proveedor B es una foto móvil de un formulario manuscrito, con las cantidades garabateadas en el margen. La del proveedor C es un documento impreso desde Excel con celdas combinadas. Un enfoque de extracción que funciona para el documento 1 falla en el documento 2. Para el documento 50, habrá encontrado todas las variaciones de formato que la cadena de suministro B2B coreana puede ofrecer, y las habrá escrito todas manualmente.
- Convenciones de nomenclatura. Necesita saber qué fila provino de qué archivo. «거래명세서_20260430.pdf» no le dice nada sobre el proveedor. Si recibe tres facturas del mismo proveedor a lo largo del mes, necesita rastrear cada línea hasta su documento original, y los nombres de archivo por sí solos no pueden proporcionar esa trazabilidad.
- Gestión de excepciones. En 50 documentos, encontrará campos en blanco. Un proveedor olvidó imprimir el precio unitario. Otro dejó vacía la celda del IVA. Una foto de móvil cortó las filas inferiores de la tabla de artículos. En el procesamiento de un solo documento, los detecta de inmediato y los resuelve. En el procesamiento por lotes, las excepciones quedan enterradas en una pila, y encontrarlas requiere revisar cada fila completada.
- Fusión de resultados. Aunque pudiera extraer cada documento a la perfección, tendría cincuenta hojas de cálculo separadas. El entregable real — el que su equipo de recepción necesita — es una única tabla con todas las líneas de todos los proveedores, ordenada y filtrable por fecha, proveedor y número de OC.
El procesamiento de un solo documento pone a prueba su velocidad de escritura. El procesamiento por lotes pone a prueba el diseño de su sistema. El cuello de botella se desplaza de «qué tan rápido puedo escribir» a «cómo manejo todos los documentos a la vez sin perder de vista de dónde vino cada uno», y esa es una pregunta fundamentalmente diferente.
Por qué Douzone, ECOUNT e iQuest no resuelven la extracción de documentos entrantes
El mercado de ERP en Corea ha invertido décadas en perfeccionar la generación de documentos salientes. Los resultados son realmente impresionantes. Douzone Bizon (더존비즈온) — el mayor proveedor de ERP de Corea, adquirido por la firma sueca de capital privado EQT por 1,3 billones de KRW en 2025 — permite a sus ~20.000 clientes corporativos generar declaraciones de transacción a partir de registros de ventas con un solo clic, completar automáticamente los campos de proveedor y comprador desde la base de datos de clientes, e imprimir o enviar por correo electrónico cientos de declaraciones en lote a través de WEHAGO e iCUBE.
ECOUNT (이카운트), que atiende a más de 80.000 clientes corporativos por una tarifa plana de 40.000 KRW al mes, sigue el mismo modelo: registro de ventas → generación automática de declaraciones de transacción → entrega multicanal (correo electrónico, KakaoTalk, SMS, fax). Su módulo de compras permite registrar datos de compras entrantes, pero la entrada de datos es manual. No existe una ruta de subir documento → extraer campos automáticamente para los documentos que usted recibe.
iQuest (아이퀘스트), creador de ERP Eolmaeyo, es el único proveedor coreano importante que ofrece extracción de datos de declaraciones de transacción basada en OCR: tome una foto de una declaración de transacción recibida con la aplicación móvil y la IA extrae la información del proveedor y la lista de artículos al ERP. Esto es un avance genuino y, en cierto modo, el análogo local más cercano a lo que ImageToTable.ai hace para documentos individuales. Pero la premisa de diseño es un documento a la vez: fotografiar, revisar la extracción de la IA en pantalla, corregir errores, confirmar, repetir. Para un vendedor de campo que captura un recibo de una comida de negocios, esto funciona. Para un equipo de compras que recibe cincuenta declaraciones de transacción de quince proveedores el último día del mes, no funciona, porque el cuello de botella no es la precisión de extracción por documento, sino el bucle de revisión humana por documento que impide el verdadero procesamiento por lotes.
Gyeongnara y Gyeongyeongiji — populares entre las pequeñas empresas coreanas por su simplicidad — gestionan competentemente la emisión de declaraciones de transacción, pero no ofrecen ninguna extracción de documentos entrantes. Tampoco las principales plataformas ASP: Popbill (팝빌), con más de 373.000 empresas registradas y más de 324 millones de documentos acumulados, y Barobill (바로빌) ofrecen API para emisión masiva e integración con HomeTax, pero sus funciones de recuperación extraen datos de sus propios documentos emitidos, no datos estructurados extraídos de documentos de proveedores que usted ha recibido en formato PDF, escaneo o foto.
El patrón es consistente en todas las plataformas coreanas de ERP y contabilidad: la automatización de documentos salientes es un problema resuelto. La extracción de datos entrantes ni siquiera está en la hoja de ruta del producto. La premisa — implícita pero uniforme — es que el comprador escribirá los datos a mano.
La realidad de fin de mes: por qué este problema tiene fecha límite
Los ciclos de pago B2B coreanos amplifican la presión del procesamiento por lotes. Dos patrones de liquidación dominan: 월말결제, donde el pago se liquida a fin de mes en que se entregaron los bienes, y 익월결제, donde el pago se liquida a fin del mes siguiente. En ambos casos, las declaraciones de transacción recibidas durante el mes se acumulan en una pila que debe conciliarse antes de autorizar el pago.
Para un fabricante o distribuidor coreano de tamaño medio con 10–30 proveedores activos, un mes típico genera entre 50 y 200 declaraciones de transacción entrantes. Llegan a lo largo del mes —unas pocas por día—, pero la conciliación ocurre en una ventana comprimida: los últimos 3–5 días hábiles antes de la autorización del pago. El departamento de recepción necesita cada línea de cada declaración de transacción en el sistema para verificar contra las órdenes de compra y preparar el calendario de pagos para el equipo de finanzas.
La aritmética de esa ventana, para un lote conservador de 50 documentos:
| Tarea | Por documento | × 50 documentos |
|---|---|---|
| Abrir y leer los campos de encabezado del proveedor/comprador | 1 min | 50 min |
| Extraer las líneas de detalle (prom. 8 filas por documento) | 3 min | 2,5 horas |
| Verificar el valor del suministro contra la OC | 1 min | 50 min |
| Verificar contra la factura fiscal (세금계산서) | 1 min | 50 min |
| Total de procesamiento manual | ~5,5 horas |
Cinco horas y media es casi una jornada laboral completa, y esto supone que cada documento llega como un PDF limpio y legible. En la práctica, el lote incluirá PDFs generados por ERP impresos en A4 estándar, formularios manuscritos de proveedores familiares pequeños que nunca han usado software de facturación, fotos móviles tomadas por repartidores y enviadas por KakaoTalk, y copias escaneadas con alineación torcida. Cada variante de formato añade fricción, y la fricción se acumula cuando trabaja contra una fecha límite.
Por eso «escribir más rápido» deja de ser una respuesta alrededor del documento veinte. La verdadera pregunta no es con qué rapidez puede teclear campos individuales, sino cómo maneja todos los documentos a la vez, en un solo flujo de trabajo, con una sola salida y con un rastro de auditoría claro que remita a cada archivo de origen.
Cómo funciona la extracción por lotes: una definición de columna para todos los proveedores
El mecanismo central que hace posible el procesamiento por lotes de declaraciones de transacción es la extracción por nombre de columna: en lugar de indicarle a una herramienta dónde encontrar cada campo en un documento (dibujando rectángulos alrededor de coordenadas o entrenando un modelo con diseños de muestra), usted le indica qué debe buscar escribiendo los nombres de los campos que desea. La IA lee el documento visualmente, localiza cada valor comprendiendo qué significa semánticamente el nombre del campo y completa la tabla de salida, sin importar dónde haya colocado el proveedor el campo en la página.
Esta distinción entre extracción basada en coordenadas y extracción semántica es lo que hace viable el procesamiento por lotes. Una herramienta basada en coordenadas necesita una plantilla distinta para el diseño de cada proveedor, porque el campo «Cantidad» del Proveedor A está en la posición de píxel (400, 320) mientras que el del Proveedor B está en (380, 450). Con cincuenta documentos de quince proveedores, necesitaría quince plantillas, y cualquiera de ellas se rompe cuando un proveedor cambia el diseño de su formulario. Una herramienta de extracción semántica necesita una sola definición de columna —una lista de nombres de campos como «Nombre del proveedor», «Fecha de transacción», «Nombre del artículo», «Cantidad», «Precio unitario», «Valor del suministro»— y aplica la misma definición a todos los documentos del lote, sin importar el diseño.
El procesamiento por lotes en ImageToTable.ai funciona bajo este principio. Usted sube los cincuenta archivos de declaración de transacción a la vez —PDF, escaneos JPG, capturas PNG, fotos WebP, todo en una sola carga. Define las columnas que desea extraer en su hoja de cálculo de salida. La IA lee cada documento, encuentra cada campo por su significado y no por su posición, y compila todos los resultados en una única tabla de Excel fusionada. Cada documento se convierte en una fila (o varias filas si contiene una tabla de artículos de varias líneas), cada campo solicitado se convierte en una columna, y usted descarga una sola hoja de cálculo, no cincuenta por separado.
Los archivos se procesan de forma segura y no se almacenan.
El multiplicador de eficiencia surge de eliminar la configuración por documento. Usted no configura nada por proveedor. No crea plantillas. No entrena modelos. Define sus columnas una sola vez —«Nombre del proveedor (공급자)», «Número de registro mercantil (사업자등록번호)», «Fecha de transacción (거래일자)», «Nombre del artículo (품목명)», «Especificación (규격)», «Cantidad (수량)», «Precio unitario (단가)», «Importe de línea (금액)», «Valor del suministro (공급가액)», «Importe del IVA (세액)», «Número de referencia de la OC»— y el mismo conjunto de columnas procesa cada declaración de transacción de cada proveedor. Cincuenta archivos, quince proveedores, una sola salida.
A 5–10 segundos por página frente a 3 minutos de entrada manual por documento, el flujo de trabajo por lotes comprime 5,5 horas de tecleo en unos 15 minutos de procesamiento —una ganancia de eficiencia de 18×—, pero la verdadera ventaja no es el tiempo ahorrado. Es que la salida llega como una única hoja de cálculo fusionada, con cada línea rastreable hasta su documento de origen, lista para la conciliación a 3 bandas contra OC y facturas fiscales.
Conciliación a 3 bandas a escala: OC → declaración de transacción (거래명세서) → factura fiscal (세금계산서)
Para los equipos de compras coreanos, extraer los datos de la 거래명세서 a una hoja de cálculo no es el objetivo final: es el paso intermedio. El entregable real es la conciliación a 3 bandas: orden de compra (발주서) → declaración de transacción (거래명세서) → factura fiscal (세금계산서).
Según el marco del IVA de Corea, la factura fiscal (세금계산서) es el documento legalmente regulado —regido por el artículo 32 de la Ley del IVA—, con campos obligatorios como los números de registro del proveedor y del comprador, el valor del suministro, el importe del IVA y la fecha de preparación. Es el documento que da derecho al comprador a la deducción del IVA soportado (매입세액 공제) y debe reflejarse con precisión en las declaraciones trimestrales del IVA (con vencimiento el 25 de enero, 25 de abril, 25 de julio y 25 de octubre). La declaración de transacción no tiene ese peso legal —es un comprobante privado (사적 증빙), no apto para deducción fiscal—, pero es el documento que realmente llega con la mercancía y contiene el detalle a nivel de artículo que la factura fiscal a menudo omite. Para el conjunto completo de documentos fiscales coreanos legalmente regulados —facturas fiscales, recibos de efectivo y certificados—, nuestra guía de extracción de documentos fiscales coreanos describe los campos de cada uno.
El flujo de trabajo de conciliación a 3 bandas a escala:
OC → declaración de transacción: verifique lo entregado frente a lo pedido
Compare los artículos, las cantidades y los precios unitarios de la declaración de transacción de cada proveedor con la orden de compra original. Las discrepancias aquí — una cantidad que no coincide, una sustitución no aprobada, un precio unitario incorrecto — deben marcarse y resolverse antes incluso de procesar la factura fiscal. Extraiga los datos de la declaración de transacción a una estructura de columnas que incluya el número de OC de cada línea.
Declaración de transacción → factura fiscal: verifique que los importes facturados coincidan con los importes entregados
La factura fiscal llega por separado — a menudo días después de los bienes, a veces adjunta a un ciclo de facturación consolidada mensual. Su valor del suministro (공급가액) y su importe del IVA (세액) deben coincidir con los totales de la declaración de transacción. Aquí es donde la hoja de cálculo fusionada da sus frutos: una columna de la extracción de la declaración de transacción, una columna de la extracción de la factura fiscal — una simple comparación en paralelo sustituye la verificación manual cruzada entre documentos separados.
Factura fiscal → declaración al NTS: verifique la exactitud de la declaración del IVA
Los datos de la factura fiscal — una vez verificados frente a la declaración de transacción — alimentan la declaración trimestral del IVA. Una discrepancia entre lo que el NTS tiene registrado de la presentación electrónica del proveedor y lo que usted declara activa una alerta de verificación cruzada. La conciliación a 3 bandas es su pista de auditoría: demuestra que lo que pagó coincide con lo que recibió y con lo que declaró el proveedor.
La combinación de la extracción de la declaración de transacción y la extracción de la factura fiscal es lo que convierte esto en un sistema completo de conciliación de compras. Cada tipo de documento contiene campos distintos, cumple una función distinta y llega por un canal distinto. Pero ambos alimentan la misma hoja de cálculo — y ambos deben coincidir.
El problema de los nombres: por qué el procesamiento por lotes necesita trazabilidad de origen
Existe un problema que no aparece en el procesamiento de un solo documento y que se vuelve crítico en los flujos de trabajo por lotes: saber qué fila extraída provino de qué archivo.
Un lote típico de cierre de mes podría incluir estos archivos:
거래명세서_20260430.pdf— de Donghae Steel, generado por ERP거래명세서_20260430.pdf— de otro proveedor, mismo nombre de archivo, carpeta diferenteKakaoTalk_20260502_143021.jpg— foto de una declaración de transacción manuscrita, proveedor desconocido solo por el nombre del archivoscan001.pdf— formulario en papel escaneado, nombre del proveedor incrustado en la imagen pero no en el nombre del archivo2026-04-30_거래명세표_대한포장.pdf— nombre de archivo claro e identificable — la excepción, no la regla
Cuando cincuenta filas extraídas llegan a su hoja de cálculo de salida, necesita saber qué fila corresponde al documento original de qué proveedor. Sin esa trazabilidad, no puede resolver una discrepancia de cantidad — no puede volver al documento de origen para verificar si la extracción fue correcta o si el proveedor cometió un error.
El flujo de trabajo de extracción por lotes en ImageToTable.ai preserva esta trazabilidad al incluir el nombre del archivo de origen como una columna en la salida. Cada fila extraída lleva el nombre del archivo original, por lo que puede rastrear cualquier dato hasta su documento de origen al instante. Para documentos con nombres de archivo ambiguos como KakaoTalk_20260502_143021.jpg, cámbieles el nombre antes de subirlos — incluso un prefijo simple como DonghaeSteel_20260430.pdf proporciona la trazabilidad que necesita.
Este es uno de esos desafíos específicos de los lotes que los tutoriales de un solo documento nunca mencionan. Cuando procesa un documento, sabe de dónde vinieron los datos porque acaba de verlo. Cuando procesa cincuenta, necesita que el sistema lo recuerde para no tener que hacerlo usted.
La convención de nombres que establezca antes de subir los archivos es su pista de auditoría. Un patrón consistente — [SupplierCode]_[Date]_[DocumentType].pdf — toma diez segundos por archivo y ahorra horas de investigación forense de nombres de archivo cuando surge una discrepancia durante la conciliación.
Manejo de la diversidad de formatos: de manuscritos a generados por ERP
El problema de la diversidad de formatos en la contratación B2B coreana es una función del tamaño del proveedor y del sector. Un gran proveedor químico en Ulsan envía mercancías con un PDF generado por Douzone iCUBE: impreso en papel láser, con formato profesional, cada campo en una cuadrícula predecible. Un pequeño proveedor de embalajes en Incheon escribe una declaración de transacción a mano en un formulario preimpreso con copias de papel carbón, arranca la copia azul del comprador (copia del comprador) y se la entrega al conductor de reparto. Un distribuidor de alimentos de tamaño medio utiliza una plantilla de Excel que parece profesional en pantalla pero que al imprimirse tiene celdas combinadas que se superponen a los límites de los campos.
El OCR convencional —que espera texto en posiciones predecibles— falla en la segunda y tercera categorías. Los caracteres coreanos manuscritos en formularios de papel carbón ya tienen bajo contraste antes de tener en cuenta la letra del conductor. Los formularios impresos desde Excel con celdas combinadas producen bloques de texto donde las etiquetas de campo y los valores se mezclan entre sí. Los sistemas basados en plantillas requieren que usted cree una plantilla separada para cada formato, y con quince proveedores que utilizan cinco tipos de formato diferentes, solo el mantenimiento de las plantillas se convierte en una tarea recurrente.
La extracción por nombre de columna maneja la diversidad de formatos por diseño, porque no depende del diseño de página. Ya sea que «Cantidad (수량)» esté en la tercera columna de una tabla de cuadrícula en un PDF, garabateada en un margen en un formulario manuscrito o incrustada en una celda combinada de Excel, la IA la localiza leyendo el documento como lo haría una persona: buscando significado semántico, no coordenadas de píxeles. La misma definición de columna que funciona en el PDF de Douzone funciona en la copia de papel carbón manuscrita y en la impresión de Excel.
Existe un límite práctico: una foto tan borrosa que una persona no pueda leer el texto también fallará para la IA. Pero el umbral de «legible» es sustancialmente más bajo que lo que requiere el OCR basado en plantillas, porque el texto borroso pero legible sigue siendo semánticamente legible, aunque sus coordenadas de píxeles sean demasiado imprecisas para que una plantilla las haga coincidir.
Gestión de excepciones en un lote de cincuenta documentos
En cualquier lote de cincuenta documentos, algunos tendrán problemas. Un proveedor dejó el campo del IVA en blanco porque es un sujeto pasivo simplificado (간이과세자) y no cobra el IVA por separado. Otro escribió el valor del suministro en la celda equivocada, por lo que la extracción devuelve un número inesperado. Una foto tomada con el móvil cortó las dos últimas filas de una tabla de artículos de diez filas.
En el procesamiento de un solo documento, usted detecta esto al instante, porque está viendo el documento y los datos al mismo tiempo. En el procesamiento por lotes, el documento y los datos extraídos están separados por el paso de extracción, y las excepciones pueden ocultarse dentro de una tabla fusionada de 400 filas.
El flujo de trabajo para gestionar excepciones en modo lote:
Busque celdas vacías en las columnas obligatorias
Tras la extracción, filtre la hoja de cálculo de salida para encontrar celdas vacías en columnas críticas: nombre del proveedor, valor del suministro, cantidad. Una celda vacía en cantidad suele significar que se omitió la fila del artículo o que el documento no contenía un campo de cantidad. En cualquier caso, necesita saberlo.
Verifique los totales contra las sumas a nivel de documento
El valor del suministro (공급가액) en la declaración de transacción es la suma de todos los importes de las líneas. Si los importes de línea extraídos no suman el valor del suministro extraído, o se omitió una línea o el valor del suministro se leyó mal. Esta verificación cruzada detecta lagunas de extracción sin necesidad de releer cada documento.
Vuelva a procesar los documentos problemáticos individualmente
Si un documento específico produjo resultados poco fiables — señalados por campos obligatorios vacíos o una discrepancia en los totales — vuelva a subirlo individualmente para una segunda pasada de extracción. El flujo de trabajo por lotes no le obliga a reprocesar todo el lote para corregir los errores de un solo documento.
La conclusión clave: el procesamiento por lotes no elimina las excepciones, cambia la forma en que las encuentra. En lugar de descubrir errores documento a documento mientras escribe, usted ejecuta comprobaciones estructuradas sobre la salida completa y aísla los documentos problemáticos. El cambio del descubrimiento reactivo de errores (encontrar fallos a medida que se cometen) a la detección proactiva de errores (escanear la salida completa en busca de anomalías) es lo que hace que el procesamiento por lotes no solo sea más rápido, sino más fiable.
Integrar la extracción por lotes en su flujo de trabajo de compras existente
La extracción por lotes de declaraciones de transacción no reemplaza su ERP, ni debería intentarlo. El ERP gestiona los registros de ventas, la generación de facturas de salida, la transmisión al NTS y los informes financieros. La extracción por lotes se encarga del paso de ingesta de datos que el ERP deja a su teclado.
El punto de integración es la salida en Excel. Extraiga todos los datos entrantes de declaraciones de transacción en una hoja de cálculo, concilie con las OC y las facturas fiscales, y luego importe los datos verificados a su ERP mediante su función estándar de importación de Excel. Todos los ERP coreanos principales admiten esto: Smart A e iCUBE de Douzone ofrecen importación por lotes desde Excel para registros de compras. ECOUNT proporciona importación masiva desde Excel para declaraciones de transacción y otros documentos de transacción. iQuest 얼마에요 admite la carga desde Excel para datos de 매입거래명세표. La hoja de cálculo extraída se convierte en la fuente de importación: limpia, estructurada y verificada antes de tocar su ERP.
Para los equipos que también procesan documentos de proveedores extranjeros, se aplica el mismo flujo de trabajo. Un albarán de entrega de un proveedor chino de componentes o una lista de empaque de un proveedor europeo de equipos siguen la misma lógica de extracción: defina columnas, cargue, obtenga una hoja de cálculo. El idioma y el formato del documento cambian, pero el principio de extracción por nombre de columna no.
Esto es fundamentalmente diferente de la promesa del ERP todo en uno. No está reemplazando su sistema financiero. Está llenando el único vacío que todo ERP coreano deja abierto: el momento en que el documento de un proveedor —en el formato que llegue— necesita convertirse en una fila de su hoja de cálculo antes de poder ser un registro en su ERP.
Preguntas frecuentes
¿El procesamiento por lotes puede manejar tanto declaraciones de transacción (거래명세서) manuscritas como impresas en la misma carga?
Sí. La IA lee cada documento de forma independiente, reconociendo caracteres coreanos manuscritos (incluida la calidad variable de la escritura) y texto impreso mediante la misma lógica de extracción semántica. La misma definición de columnas procesa ambos formatos. El límite práctico es la legibilidad: si una persona no puede leer la escritura, es probable que la IA tampoco pueda.
¿Qué ocurre cuando la declaración de transacción (거래명세서) de un proveedor utiliza nombres de campo no estándar?
La extracción de nombres de columna no coincide con cadenas de texto: localiza los valores mediante comprensión semántica. Un proveedor cuyo formulario etiqueta el campo de cantidad como «출하수량» (cantidad de envío) en lugar de «수량» (cantidad) se extraerá correctamente de todos modos, porque la IA entiende que ambas etiquetas se refieren al mismo concepto. Esta es la diferencia fundamental entre la coincidencia de plantillas (que fallaría) y la extracción semántica (que se adapta).
¿Cómo gestiona el sistema las declaraciones de transacción (거래명세서) de varias páginas con tablas de artículos que abarcan varias páginas?
Los PDF de varias páginas se procesan como un único documento. La IA lee todas las páginas y extrae todas las líneas de la tabla de artículos, independientemente de los saltos de página. El resultado consolida todas las filas de todas las páginas en el registro del mismo documento en la hoja de cálculo.
¿Puedo extraer solo líneas específicas, por ejemplo, solo los artículos que coincidan con un número de OC concreto?
El paso de extracción extrae todos los datos de todos los documentos. El filtrado por número de OC, proveedor, rango de fechas o cualquier otro criterio se realiza en la hoja de cálculo de salida después de la extracción, lo que le ofrece el conjunto de datos completo para trabajar y filtrar según sea necesario, en lugar de restringir la extracción a un subconjunto de antemano.
¿Cumple la extracción de datos de declaraciones de transacción (거래명세서) con los requisitos coreanos de conservación de registros fiscales?
La 거래명세서 en sí es un comprobante privado (사적 증빙): no tiene un formato legalmente obligatorio ni se presenta ante ninguna autoridad gubernamental. No existen requisitos de cumplimiento específicos que regulen cómo extrae o almacena sus datos. La factura fiscal (세금계산서), regulada por el artículo 32 de la Ley del IVA, es el documento con obligaciones legales de cumplimiento, y se gestiona por separado. Para la extracción de facturas fiscales, consulte la guía de procesamiento por lotes de facturas fiscales. En la práctica, la Ley Marco de Impuestos Nacionales (국세기본법), artículo 85-3, recomienda conservar los registros de transacciones durante cinco años, y un archivo Excel estructurado con trazabilidad del nombre del archivo de origen cumple este propósito mejor que una pila de formularios en papel.
¿Esto también funciona para facturas fiscales coreanas (세금계산서) por lotes?
Sí — se aplica el mismo flujo de extracción por lotes. Para el procesamiento por lotes de facturas fiscales, defina columnas como número de registro mercantil (사업자등록번호), valor del suministro (공급가액), importe del IVA (세액) y número de aprobación (승인번호), y procese de 100 a 200 facturas fiscales en una sola carga. El principio de extracción es idéntico; solo cambian los nombres de los campos.
Cualquier ERP coreano puede generar una declaración de transacción a partir de un registro de ventas. La brecha —y la oportunidad— está en el lado receptor. La extracción por lotes la cubre con una definición de columna, una carga y una hoja de cálculo. Pruébelo en su próximo lote de fin de mes. Vea si 5,5 horas de tecleo se convierten en 15 minutos de verificación.