파이썬으로 PDF에서 인보이스 데이터 추출하기

파이썬으로 PDF에서 인보이스 데이터를 추출하려면 파일에서 텍스트를 읽어온 다음 해당 텍스트에서 명명된 필드를 끌어내면 됩니다. 두 단계, 어쩌면 40줄의 코드로 첫 번째 인보이스에서 훌륭하게 작동할 것입니다. 하지만 일곱 번째 공급업체가 인보이스 번호를 세 줄 위로 올리면, 여러분의 파서는 새벽 2시에 None을 반환하기 시작합니다.

이 두 번째 부분이 이 글의 진정한 주제입니다. 읽는 것은 쉽습니다. 정확성을 유지하는 것이 진짜 일입니다.

핵심 요약

• 파이썬은 몇 줄의 코드로 인보이스 텍스트를 추출할 수 있습니다. 수백 개의 공급업체 레이아웃 전반에 걸쳐 정확성을 유지하는 데 실제로 비용이 듭니다.
• PDF는 데이터 포맷이 아닙니다. 인쇄된 페이지에 대한 타이포그래피 설명이므로, 한 공급업체의 레이아웃에 맞춰 작성된 정규식은 깨지기 쉽습니다.
• 정규식과 공급업체별 템플릿은 공급업체 목록과 선형적으로 확장됩니다. 비전 모델은 문자열 대신 페이지를 읽기 때문에 그렇지 않습니다.
• 데이터를 무엇으로 추출하든, 산술 검증은 자체 코드로 확인해야 합니다. 소계와 합이 맞지 않는 개별 항목은 여러분이 작성하게 될 가장 비용 효율적인 버그 탐지기입니다.
• 데이터 추출 자체 때문에 시스템 구축을 포기하는 경우는 드뭅니다. 예외 처리 큐, 공급업체 매칭, 회계 시스템 통합이 진짜 장애물입니다.

PDF 포맷

PDF 포맷은 인보이스 등 종이 문서를 디자인의 제약 없이 정확하게 디지털로 표현할 수 있도록 해줍니다. 이 형식은 종이 인쇄 세계에서 비롯되었으며, 실제 인쇄 페이지의 디지털 재현을 염두에 두고 개발되었습니다. 이처럼 유연성이 크기 때문에, PDF 작성자는 자유롭게 문서를 표현하면서 각종 표준과 규제도 준수할 수 있습니다.

하지만 PDF 내부에 데이터가 잠겨 있는 경우, 이것을 꺼내는 데 어려움이 따릅니다. PDF의 자유롭고 복잡한 구조는, 기업이 매일 처리해야 하는 방대한 데이터를 체계적이고 일관되게 관리해야 하는 현실과 서로 충돌할 수 있습니다.

PDF는 각 글리프(glyph)가 페이지의 어디에 위치하는지를 저장합니다. 오른쪽 하단의 숫자가 총액이라는 사실을 저장하지는 않습니다. 이러한 관계는 여러분의 머릿속에 있으며, 이 글에 소개된 모든 추출 방법은 그것을 코드로 변환하려는 시도입니다.

인보이스에서 데이터를 추출하는 단계

인보이스는 대부분 PDF 형식입니다. 인보이스는 공급자와 고객 사이의 거래를 공식화하며, 상품 또는 서비스가 일정 금액과 맞바뀌었음을 증명합니다. 이 문서에서 데이터를 추출하려면 다음과 같은 절차가 필요합니다:

1. 인보이스에서 추출할 데이터의 구조(스키마)를 정의합니다.
2. 인보이스를 이미지에서 텍스트로 변환합니다.
3. 데이터 스키마에 따라 인보이스에서 텍스트를 추출합니다.
4. 추출된 데이터를 수집합니다.

인보이스 데이터 스키마 정의

인보이스는 다양한 공급자별로 각각의 방식과 형식으로 커스터마이즈됩니다. 하지만 실질적으로 모든 인보이스에는 공급자 정보, 고객 정보, 인보이스 번호, 날짜, 그리고 각 항목(수량, 설명, 단가, 가격) 목록이 반드시 필요합니다. 인보이스 데이터 포맷을 정의할 때 가장 좋은 출발점은 사용하는 회계 소프트웨어의 구조를 참고하는 것입니다. 결과적으로 추출된 데이터를 저장하게 될 곳이 바로 회계 소프트웨어니까요. 만약 모든 예외 상황까지 포함하는 포맷이 필요하다면 schema.org을 추천합니다. 이 사이트에는 인보이스 등 많은 산업 표준 데이터 포맷이 편리하게 정의되어 있습니다. Parseur는 인보이스의 기본 데이터 스키마를 정의하지만, 인보이스 메일박스 내 필드명을 바꿔서 여기서 설명한 대로 스키마를 사용자 목적에 맞게 변경할 수 있습니다. 데이터 포맷이 정해졌다면, 이제 인보이스를 이미지에서 텍스트로 변환할 수 있습니다.

예를 들어, 아래처럼 JSON Swagger 포맷으로 인보이스 필드를 정의할 수 있습니다:

{
    "InvoiceNumber": {
        "type": "string",
        "description": "The invoice number"
    },
    "InvoiceIssueDate": {
        "type": "string",
        "description": "The invoice date"
    },
    "Items": {
        "type": "array",
        "description": "The list of items in the invoice",
        "items": {
            "type": "object",
            "properties": {
                "quantity": {
                    "type": "number",
                    "description": "The quantity of the item"
                },
                "description": {
                    "type": "string",
                    "description": "The description of the item"
                },
                "unit_price": {
                    "type": "number",
                    "description": "The unit price of the item"
                },
                "price": {
                    "type": "number",
                    "description": "The total price of the item"
                }
            }
        }
    }
}

파싱 코드를 작성하기 전에 이것을 먼저 적어두세요. 이것은 아래의 모든 방법이 충족해야 하는 계약이며, 나중에 비전 모델에 전달할 내용입니다.

인보이스를 이미지에서 텍스트로 변환하기

PDF 파일에는 이미지가 포함되어 있을 수 있습니다. 예를 들어, 직원이 인보이스를 스마트폰 카메라로 촬영할 수 있습니다. 그 후 PDF로 저장해서 회계팀에 전달합니다. 회계팀은 이 인보이스에서 데이터를 추출해 오류 없이 회계 시스템에 입력해야 합니다. 다음 단계에서는 광학 문자 인식(OCR) 시스템을 이용해 이미지를 텍스트로 변환해야 합니다. 대표적인 OCR 시스템으로는 Tesseract가 있습니다. Tesseract는 C와 C++로 작성되어 있습니다. 파이썬 프로그램에서 Tesseract를 사용하려면 PyTesseract 같은 바인딩이 필요합니다. 바인딩이란 특정 언어(여기서는 파이썬)에서 작성되지 않은 소프트웨어 라이브러리(여기서는 Tesseract)를 호출할 수 있게 도와주는 인터페이스를 말합니다. 여러 OCR 소프트웨어가 존재하며, 각기 다른 기본 기술과 다루고 있는 문서의 스캔 품질에 따라 결과가 크게 다를 수 있습니다. Parseur는 문서가 이미지인지 여부를 투명하게 감지해서 내부적으로 텍스트로 자동 변환합니다. 문서 데이터가 텍스트화되면 추출할 준비가 완료된 것입니다.

데이터 스키마에 따라 인보이스에서 텍스트 추출하기

PDF가 텍스트(또는 검색 가능한) 형태가 되면, pdftotext 파이썬 라이브러리를 이용해 PDF 파일에서 데이터를 텍스트로 가져올 수 있습니다. 아래는 PDF 파일에서 텍스트를 추출하는 파이썬 코드 스니펫입니다:

import pdftotext

# 인보이스 불러오기
with open("invoice.pdf", "rb") as file_handle:
    pdf = pdftotext.PDF(file_handle)

# 모든 페이지 반복 처리
for page in pdf:
    print(page)

이 스크립트를 convert_pdf_to_text.py로 저장해 실행하면 인보이스가 텍스트로 표준 출력에 나타납니다. 출력 결과를 파일로 리디렉션하려면 다음과 같이 실행하세요:

$ python convert_pdf_to_text.py > invoice.txt

pdftotext는 단순한 평면 문자열을 제공하므로 헤더 필드에는 괜찮지만 표에는 가망이 없습니다. 개별 항목이 필요하다면 모든 단어의 좌표를 유지하고 표 자체를 시도할 수 있는 pdfplumber를 사용하세요:

import pdfplumber

with pdfplumber.open("invoice.pdf") as pdf:
    page = pdf.pages[0]

    # 페이지 내 단어와 그 위치
    for word in page.extract_words():
        print(word["text"], word["x0"], word["top"])

    # 개별 항목 표 추출 시도
    table = page.extract_table()
    if table:
        for row in table:
            print(row)

실제 공급업체 인보이스에 이를 실행해 보면 table이 None인 경우가 아주 많을 것입니다. 이는 버그가 아닙니다. 이 문제가 보기보다 어렵다는 것을 보여주는 첫 번째 정직한 신호이며, 아래에서 다시 다루겠습니다.

이제 텍스트 형태의 인보이스가 생겼으니, 다음 기술을 조합하여 원하는 데이터를 추출할 수 있습니다:

• 정규표현식을 사용해 원하는 데이터를 추출할 수 있습니다. 정규표현식은 텍스트에서 데이터를 추출할 때 강력하지만, 포맷이 바뀌면 수정을 반복해야 하고 표 형태 데이터 추출에는 약합니다.
• 동적 OCR 및 영역 OCR을 이상적으로 활용하는 시각적 템플릿 시스템을 사용할 수 있습니다. 텍스트에서 데이터를 추출하는 더 발전된 방식입니다. 정규표현식보다 견고하지만 구현이 더 복잡합니다.
• 페이지를 스키마와 함께 비전 모델에 전달하여 사람이 문서를 읽는 방식으로 문서를 읽게 할 수 있습니다. 이는 지난 2년 동안 변화한 접근 방식이며, 아래 별도 섹션에서 다룹니다.

파이썬 re 모듈을 사용하여 인보이스에서 데이터를 추출해 보겠습니다. 아래는 인보이스 번호를 추출하는 파이썬 코드 스니펫입니다:

import re

# 인보이스 텍스트 파일 읽기
with open("invoice.txt", "r") as file_handle:
    invoice = file_handle.read()

# 인보이스 번호 추출
invoice_number = re.search(r"Invoice number: (\w+)", invoice).group(1)
print(invoice_number)

이 코드를 extract.py로 저장해 실행하면 인보이스 번호가 표준 출력에 표시됩니다:

$ python extract.py

그러면 다음과 같은 결과를 얻게 됩니다:

INV-1234

정규식 인보이스 파서가 망가지는 이유

정규식은 문자열을 일치시킵니다. 인보이스는 그림입니다. 잘못되는 모든 문제는 그 불일치에서 발생하며, 예측 가능한 몇 가지 방식으로 잘못됩니다:

• 레이블 이동. 패턴은 Invoice number:에 고정되어 있는데 새 템플릿에는 Invoice #라고 적혀 있거나, 값을 같은 줄이 아니라 다음 줄에 넣습니다.
• extract_table이 None을 반환. 표 추출기는 테두리 선을 찾습니다. 대부분의 공급업체 인보이스는 공백으로 열을 맞추며 테두리를 전혀 그리지 않습니다.
• 텍스트가 잘못된 순서로 나옴. 페이지가 문자열로 평면화될 때 2열 레이아웃과 떠 있는 주소 블록이 뒤섞여 개별 항목 행이 섞인 채 도착합니다.
• 표가 페이지를 넘어감. 29행은 1페이지에, 1014행은 2페이지에 있으며 그 사이에 열 헤더가 반복되고 소계 줄이 항목인 척합니다.
• 세 가지 숫자가 모두 총액처럼 보임. 소계, 총계, 청구 금액, 이월 잔액. 크레딧(환불 내역 등)이 있는 인보이스에서는 가장 큰 숫자를 고르는 것이 틀립니다.
• 스캔본이 사진임. OCR은 번진 8을 3으로 읽고 다운스트림에서는 아무것도 눈치채지 못합니다. 3은 완전히 유효한 숫자이기 때문입니다.
• 병합된 셀 및 여러 줄 설명. 한 제품 설명이 세 줄로 줄 바꿈되고 행 분할 로직이 이를 가격이 없는 세 개의 항목으로 바꿉니다.

이 중 어느 것도 더 나은 정규 표현식으로 고칠 수 없습니다. 이들은 모두 문자열 문제의 옷을 입은 레이아웃 문제입니다. 이 시점이 되면 대부분의 사람들은 계속 늘어나는 공급업체당 템플릿 하나를 작성하기 시작하거나 접근 방식을 바꿉니다.

2026년식 접근 방식 - 비전 모델과 스키마

유용한 변화는 데이터 추출 전 더 이상 페이지를 텍스트로 평면화할 필요가 없다는 것입니다. 비전 모델은 렌더링된 인보이스를 보므로, 공급업체가 인보이스 번호를 옮기는 것은 더 이상 문제가 되지 않습니다. 여러분이 제공하는 것은 패턴이 아니라 이 글 맨 위에서 작성한 스키마입니다.

매번 동일한 키를 얻을 수 있도록 출력을 제한하세요. Pydantic에 OpenAI structured outputs와 같은 구조화된 출력 모드를 결합하면 그 작업을 대신 해줍니다:

from typing import List
from pydantic import BaseModel

class LineItem(BaseModel):
    description: str
    quantity: float
    unit_price: float
    amount: float

class Invoice(BaseModel):
    vendor_name: str
    invoice_number: str
    invoice_date: str      # ISO 8601
    currency: str
    subtotal: float
    tax: float
    total: float
    line_items: List[LineItem]

# PDF 페이지를 이미지로 렌더링하고, 비전 모델에 전송한 뒤,
# 응답이 Invoice 스키마와 일치하도록 요구합니다.
# 모델은 필드를 채우지만, 형식을 발명할 수는 없습니다.

이것이 진정으로 추출 문제의 대부분을 해결한 것이며, 이 접근 방식이 그렇게 빨리 퍼진 이유입니다. 하지만 이는 정규식에는 없었던 새로운 실패 모드도 도입합니다. 인보이스 번호를 찾지 못한 정규식은 None을 반환하지만, 이를 찾지 못한 모델은 때때로 그럴듯한 번호를 작성합니다. 여러분을 안전하게 지켜주는 규칙은 간단합니다. 모델이 제안하고 여러분의 코드가 검증하는 것입니다.

모델을 직접 실행하고 싶지 않다면, Azure AI Document Intelligence 및 Amazon Textract의 AnalyzeExpense와 같이 클라우드 제공업체에서 관리형 서비스로 판매되는 동일한 기능을 이용할 수 있으며 둘 다 헤더 필드와 개별 항목을 별도로 반환합니다. 기반 접근 방식이 규칙 기반 파싱과 어떻게 다른지 AI vs 규칙 기반 PDF 파서에서, 인보이스에 특별히 적용된 모습이 어떤지 비전 AI 인보이스 처리에서 작성했습니다.

직접 작성해야 하는 유효성 검증 계층

JSON을 무엇으로 생성했든 이러한 검사는 추출기의 신뢰도 점수가 아니라 여러분의 코드에 있어야 합니다. 저렴하고 결정론적이며 금전적 손실을 초래하는 오류를 잡아냅니다:

1. 소계 + 세금 + 배송비 - 할인이 센트 단위 오차 내에서 총액과 일치해야 합니다.
2. 개별 항목의 합이 소계가 되어야 합니다. 그렇지 않다면 행을 누락했거나 없는 행을 만들어낸 것입니다.
3. 모든 수량 * 단가는 자체 금액(amount)과 같아야 합니다.
4. 날짜가 파싱되어야 하며 미래 날짜가 아니어야 합니다.
5. 해당 공급업체에 대한 인보이스 번호로 이미 결제된 내역이 없어야 합니다. 중복 결제는 지급 계정(AP)에서 가장 비용이 많이 드는 버그입니다.
6. 공급업체 이름이 마스터 데이터 기록의 공급업체 정보로 해석되어야 합니다.
7. 송금할 은행 세부 정보가 해당 공급업체에 대해 이미 등록된 정보와 일치해야 합니다. 이 정보의 변경은 데이터 검사가 아니라 사기(fraud) 확인 과정입니다.
8. 실제로 거래하는 통화여야 합니다.
9. 구매 주문 번호가 존재하며, 양방향 또는 3방향 매칭을 실행하는 경우 그 수량과 가격이 일치해야 합니다.
10. 모든 필수 필드가 존재하고 비어 있지 않아야 합니다.

실패하는 것은 장부에 기록되는 대신 사람이 직접 확인해야 합니다:

def validate(invoice):
    errors = []

    if abs(invoice.subtotal + invoice.tax - invoice.total) > 0.01:
        errors.append("totals_do_not_add_up")

    line_sum = sum(item.amount for item in invoice.line_items)
    if invoice.line_items and abs(line_sum - invoice.subtotal) > 0.01:
        errors.append("line_items_do_not_sum_to_subtotal")

    if not invoice.invoice_number:
        errors.append("missing_invoice_number")

    return errors

10줄의 산술 연산이 아무리 많은 프롬프트 튜닝보다 더 많은 실제 문제를 잡아낼 것입니다.

invoice2data와 다른 라이브러리들은 어떨까요?

invoice2data는 정직하게 언급할 가치가 있습니다. 많은 사람들이 가장 먼저 찾는 결과물이며 진정으로 좋은 소프트웨어이기 때문입니다. 이것은 코드가 아니라 버전 관리에 매칭 규칙을 둔 채, 공급업체별로 작성한 YAML 템플릿과 인보이스를 일치시키는 명령줄 도구이자 파이썬 라이브러리입니다. 레이아웃을 절대 바꾸지 않는 십여 곳의 공급업체가 있다면 수년간 잘 작동할 것입니다.

한계는 품질이 아니라 설계에 있습니다. 공급업체당 템플릿 하나라는 것은 공급업체 목록이 길어질수록 유지보수 작업이 늘어난다는 뜻이며, 템플릿은 위에서 나열한 이유로 정확히 깨집니다. 활성화된 레이아웃이 20~30개를 넘어서면 템플릿을 유지보수하는 사람이 예전에 인보이스를 타이핑하던 사람보다 더 많은 일을 하게 됩니다.

광범위한 라이브러리들에도 동일한 논리가 적용됩니다. pdfplumber, PyMuPDF, pdftotext, pytesseract는 모두 페이지에서 문자와 좌표를 가져오는 실제 작업에 아주 뛰어납니다. 하지만 이들 중 어느 것도 어떤 숫자가 총액인지 알도록 설계되지 않았습니다. 더 광범위한 라이브러리 비교는 최고의 PDF 파서 및 최고의 데이터 추출 API 요약본에서 확인할 수 있습니다.

추출한 데이터 수집하기

파이썬을 사용하면 특정 폴더에 있는 인보이스 파일들을 반복하며 그 안에서 데이터를 추출할 수 있습니다. 인보이스 번호와 총액을 추출하고 CSV 형식으로 결과를 출력해 보겠습니다:

import os
import re

import pdftotext

# 폴더 내 모든 PDF 파일 반복
for filename in os.listdir("invoices/"):
    if not filename.endswith(".pdf"):
        continue

    # 인보이스 불러오기
    with open("invoices/" + filename, "rb") as file_handle:
        pdf = pdftotext.PDF(file_handle)

    # CSV 열 헤더 출력
    print("InvoiceNumber,TotalAmount")

    # 모든 페이지 반복
    for page in pdf:
        # 인보이스 번호 및 총 금액 추출
        invoice_number = re.search(r"Invoice number: (\w+)", page).group(1)
        total_amount = re.search(r"Total amount: (\w+)", page).group(1)
        print(invoice_number, total_amount, sep=",")

이 스크립트를 extract_to_csv.py로 저장해 실행하면 인보이스 번호와 총 금액이 표준 출력에 표시되고, 이것을 CSV 파일로 리디렉션하여 나중에 Excel과 같이 즐겨 쓰는 스프레드시트 소프트웨어로 열 수 있습니다:

$ python extract_to_csv.py > invoices.csv

대부분의 인보이스 스크립트는 CSV 파일 폴더에서 끝나며, 이것은 진정한 회계 작업이 시작되는 곳이기도 합니다. 누군가는 여전히 파일을 가져오고, 공급업체를 매칭하고, 회계 시스템이 거부한 행을 추적하고, 새벽 2시에 유효성 검사에 실패한 인보이스로 무엇을 해야 할지 알아내야 합니다. 그 작업은 스크립트에 나타나지 않으며 토큰 청구서에도 나타나지 않습니다.

자체 구축을 중단해야 할 때

여기가 대부분의 공급업체가 건너뛰는 부분이니 저희가 먼저 말씀드리겠습니다. 안정적인 공급업체가 소수이고, 파이프라인을 지켜볼 수 있는 엔지니어가 있으며, 데이터를 기다리는 사람이 없다면 스크립트를 작성하세요. 비전 모델과 스키마, 그리고 10줄의 유효성 검사 코드로 적은 비용으로도 많은 작업을 해낼 수 있고 모든 과정을 이해할 수 있습니다.

구축에 따른 비용 청구서는 나중에 도착하며, 데이터 추출에서 발생하지는 않습니다. 그것은 아무도 프로토타입을 만들지 않은 부분에서 도착합니다:

• 예외 큐(The exception queue). 지급 계정(AP) 팀은 40초가 아닌 4초 만에 수정할 수 있도록 필드를 클릭하면 인보이스에서 강조 표시되는 화면이 필요합니다. 그것은 스크립트가 아니라 제품입니다.
• 공급업체 매칭. "ACME Ltd", "Acme Limited", "ACME LTD."는 하나의 공급업체이며 원장은 세 개를 받아들이지 않습니다.
• 중복 감지. 동일한 인보이스가 화요일에는 이메일 첨부 파일로, 금요일에는 명세서 PDF로 도착합니다.
• 상태 머신. 큐, 재시도, 부분 실패, 어젯밤 300개의 인보이스 중 어느 것이 실제로 성공했는지 파악해야 합니다.
• 감사 추적. 추출된 내용, 사람이 변경한 내용, 누가 언제 승인했는지. 재무 부서에서는 보통 감사 기간에 질문할 것입니다.
• JSON 이후의 모든 것. 회계 시스템으로의 필드 매핑, GL 코딩, 구매 주문 매칭 및 시스템이 거부한 행의 처리.

직접 구축하기보다 비용을 지불해야 할 시점이라는 분명한 신호는 다음과 같습니다. 활성 공급업체 레이아웃이 20~30개를 넘어섰을 때. 헤더 필드뿐만 아니라 개별 항목이 필요할 때. 스캔본으로 도착하는 인보이스가 소수 이상일 때. 엔지니어링 팀이 아니라 AP 팀이 실수를 수정해야 할 때. 실패한 추출로 인해 결제가 지연될 때. 또는 가장 흔한 경우로, 파서를 유지보수하는 사람이 다른 어떤 것도 배포하지 못하고 있을 때입니다.

Parseur의 처리 방식

Parseur는 추출 단계뿐만 아니라 전체 루프를 수행하는 문서 파서입니다. 인보이스는 전용 메일박스 주소, API, 또는 감시 폴더를 통해 도착합니다. 비전 AI 엔진은 PDF, 스캔 및 사진을 읽고, 텍스트 AI 엔진은 이메일과 텍스트 문서를 읽습니다. 필드에 이름과 유형이 지정되어 나오며, 개별 항목은 행으로 나옵니다. 작성할 템플릿이 없고 공급업체가 인보이스를 재설계할 때 유지보수할 사항도 없습니다.

JSON 위에서 얻는 것은 이 글에서 경고해 온 나머지 절반입니다. 추출된 데이터는 그 자리에서 검토 및 수정이 가능하므로 AP 직원이 티켓을 열지 않고 잘못 읽힌 총액을 바로 수정합니다. 수정 사항은 다시 추출 기능으로 피드백됩니다. 그리고 데이터는 직접 웹훅 통합, Make, Zapier 또는 Microsoft Power Automate를 통해, 또는 API에서 곧바로 JSON으로 나가 필요한 곳으로 이동합니다.

저희가 기본적으로 인보이스에서 추출하는 필드 세트를 보고 싶다면 인보이스 OCR 페이지에 문서화되어 있으며, 더 넓은 워크플로우는 인보이스 데이터 캡처에서 다룹니다.

결론

파이썬으로 PDF에서 인보이스 데이터를 추출하는 것은 100여 개의 인보이스에 대해서는 해결된 문제지만 1만 개에 대해서는 미해결 문제에 가깝습니다. 그 두 숫자 사이에서 변하는 것은 코드가 아닙니다. 변하는 것은 조용히 유지보수하기로 등록하고 있는 공급업체 레이아웃이 얼마나 많은지, 그리고 그중 하나가 이동했을 때 호출받을 사람이 누구인지입니다.

스크립트를 작성해 보세요. 위에서 언급한 7가지 실패 모드 중 어떤 것을 가장 먼저 겪게 될지 알아보기 위해서라도, 단 한 번은 직접 해볼 가치가 있습니다. 그런 다음 향후 6개월의 시간을 여덟 번째 실패 모드에 쓰는 것이 진정 최선일지 정직하게 결정하세요. 만약 대답이 '아니요'라면, Parseur는 2016년부터 이 작업을 해오고 있으며 여러분의 인보이스 폴더 업무를 흔쾌히 넘겨받을 것입니다.

마지막 업데이트 2026년 8월 13일