뉴스

앱에서 변경된 사항과 그 의미에 대한 설명입니다. 가장 최신 내용이 위에 있습니다.

오직 여러분이 작업할 때 알 수 있는 것만 포함되어 있습니다: 새로운 기능, 동작 변경 및 수정 사항. 새로운 기록이 추가되면 도움말 탭에 점이 생기고, 이 페이지를 열면 사라집니다.

앱은 지속적으로 배포되므로 버전 번호가 없고, 날짜만 있습니다.

2026년 9월 18일

할인 후 가격. 송장이 할인 전과 후 가격을 모두 출력하는 경우(대형마트 영수증, 건축 자재 청구서 등) 할인 후 가격이 추출됩니다. 이전에는 첫 번째 가격이 데이터에 포함되어 실제로 지불한 금액보다 높은 비용이 발생했습니다.

항목 요금 검사를 위한 세금 확인. 외화로 발행된 청구서는 해당 화폐의 세금 열을 포함하는 경우가 많아 처음 봤을 때 모든 것이 맞아 보입니다: 세금 포함 금액은 지불할 금액과 일치하며 항목은 기본 금액에 맞습니다. 그러나 행의 세금 요율이 일치하지 않으면 문제를 인식합니다. 그런 청구서는 이제 발견됩니다. 수정 버튼은 고의로 제공되지 않으며, 세금과 지불할 금액이 모두 잘못되었고, 두 개의 필드를 동시에 수정해야 하는 청구서는 사람의 손이 필요한 경우입니다.

세율 대신 세금 금액을 수정합니다. 독일 청구서의 "MwSt." 열에 유로로 금액이 표시되고, 세율에 19.84%가 포함되는 경우가 있습니다. 이러한 세율이 EU에서 유효하지 않을 때에만 수정됩니다. 금액으로 읽으면 유효한 세율이 도출되고, 계산된 세금은 청구서 요약에 정확히 반영됩니다.

외화 부가세 요율은 더 이상 문제로 표시되지 않습니다. 폴란드 23%, 오스트리아 20%, 포르투갈 6%는 이전에 비정상적인 요율로 보고되었습니다. 국내 청구서는 발행 날짜에 따른 체코 요율에 맞춰 계속해서 측정됩니다.

항목의 누락된 세율을 보충합니다. 할인, 반올림 또는 보증금 공제는 세율 열에 대시로 표시되는 경우가 많습니다. 이렇게 된 행은 이전에 제로 세율로 떨어지며, 청구서에 표시된 내용과 요약이 일치하지 않게 되었습니다. 세율은 합계로 확인된 경우에만 보충됩니다.

세금 포함 가격인 항목이 재계산됩니다. 청구서에서 항목의 가격은 세금 제외 가격이며, 모델이 세금 포함 금액을 사용할 때마다 회계로 송금되는 기본 금액이 세율로 부풀려졌습니다. 92개의 청구서 샘플 중 15개가 이에 해당합니다. 이전에 추출된 문서는 새로운 처리 없이 되돌려 계산되며 크레딧 없이 진행됩니다.

이메일 (.eml) 업로드. 저장된 메일을 업로드하면 각 첨부 파일에서 문서가 생성됩니다. 문서가 생성되지 않은 첨부 파일에 대해서는 이유를 알 수 있습니다.

IČO가 같은 측의 DIČ와 비교됩니다. 체코 기업의 DIČ는 해당 기업의 IČO를 포함하고 있어 둘 다 같은 회사에 속함을 확인할 수 있습니다. 이는 공급자와 수령자의 전환을 포착하는 데 유용하며, 주제 수치의 확인으로는 충분하지 않습니다. 두 숫자 모두 유효하더라도 다른 사람에게 속할 수 있습니다. 이 발견에 대한 수정은 한 번의 클릭으로 진행될 수 있습니다.

2026년 9월 17일

문서는 두 번 처리되지 않습니다. 작업 대기열이 같은 문서를 두 번 배송하는 경우 두 번째 시도는 중단됩니다. 작업이 중단된 문서는 10분 후 대기 중으로 돌아갑니다.

Webhook 및 Telegram 메시지는 문서 저장 후에만 전송됩니다. 처리 종료와 저장 사이의 짧은 순간에 webhook이 아예 전송되지 않거나 Telegram이 실패한 문서에 대해 "완료"라고 알리는 경우가 있었습니다.

2026년 9월 16일

모델 한도가 충족되지 않더라도 문서가 중단되지 않습니다. 대량의 데이터 전송 후 매일 처리 한도를 초과한 문서가 이전에는 오류로 기록되었습니다. 이제 대기열에 대기하고 한도가 해제되면 처리됩니다 — 오류 메시지 없이 크레딧을 변동 없이 유지합니다.

큰 배치가 다른 작업을 차단하지 않습니다. 대기열은 고객을 번갈아 처리하므로, 수천 개의 문서를 가져오는 작업이 동시에 누군가가 업로드한 문서를 중단시키지 않습니다.

더 정확한 데이터 추출. 데이터 모델은 새로운 모델로 전환되었습니다: 확인 세트에서 98.4% 정확한 필드가 기존의 88.0%에서 유지됩니다. 산발적인 부정확성과 코드에서 0과 문자 O의 혼동이 사라졌습니다.

디지털 PDF는 텍스트 레이어에서도 읽힙니다. 페이지 이미지 옆에 파일의 텍스트가 함께 추출되므로 이미지에서 혼동될 수 있는 내용도 읽힙니다. 샘플에서 정확도가 98.4%에서 100%로 증가했습니다.

체코 회사의 IČO는 8자리 숫자여야 합니다. 이전에는 추가 숫자가 전혀 평가되지 않아 외국 등록 번호가 잘못된 문제로 처리되지 않았습니다. 체코 회사라는 사실은 DIČ를 통해 확인할 수 있습니다.

발견이 있는 문서 확인에는 명확한 동의가 필요합니다. 발견이 있는 문서는 자동으로 통과되지 않으며: 발견은 창에 표시되며 그럼에도 불구하고 확인 버튼을 통해 확인됩니다. 두 개의 0이 누락된 IBAN을 간과할 경우 다른 필드의 수정 사항에 섞여버리지 않습니다.

미리보기에서 검색 시 데이터에서도 검색됩니다. 원본 왼쪽에서 찾은 내용은 오른쪽에서도 강조 표시됩니다. 청구서에서 가져온 금액("16 591,56")은 JSON이나 XML에서도 그에 상응하는 항목을 찾습니다.

처리는 별도의 서비스에서 진행됩니다. 새로운 버전의 배포로 인해 진행 중인 문서가 중단되지 않게 되었습니다.

2026년 9월 15일

완료된 문서를 수정합니다. 창의 상단에 두 가지 경로가 있는 버튼이 있습니다: 문서를 검사로 되돌리고 데이터를 수정하는 것(비용 없음) 혹은 다른 유형으로 다시 처리하는 것입니다. 이전에는 잘못된 결과의 문서에서는 삭제하고 크레딧이 다시 필요하기 때문에 재업로드하는 것밖에 할 수 없었습니다.

일반 영수증이 새로운 문서 유형으로 추가되었습니다. 레스토랑 영수증은 이전에 연료 영수증으로 처리될 수 있었으나, 이제는 일반 영수증 스키마가 추가되어 연료 영수증에 연료가 없을 경우 발견이 그것을 알립니다.

ISDOC 영수증이 간소화된 세금 문서로, 기존의 Pohoda 및 Money S3와 함께 사용됩니다.

ISDOC 공식 스키마 6.0.2. 기존 스키마 출력이 일치하지 않으며 필수 문서의 절반이 누락되었습니다. 이제는 자동으로 검증됩니다.

해당 유형의 문서 형식은 생성되지 않습니다. 해당 변환을 다운로드할 수 없었으나, 세부사항, 미리보기, 웹훅 및 MCP는 이를 생성했습니다. 이제는 모든 곳에서 동일한 오류 메시지를 반환합니다.

세금 없이 청구서는 항목 요약을 포함하지 않습니다. 비과세자의 문서에서는 경우에 따라 총합, 총계 및 지불 금액 항목이 분류에 포함될 수 있어 잘못된 합계가 발생할 수 있습니다.

검증 후 확인하면 다음 대기 문서가 열립니다. 이전에는 창이 확인된 문서에 남아 있어 다음 문서로 이동하려면 모든 항목 사이를 화살표로 이동해야 했습니다.

화살표 이동이 기본 탭을 엽니다. 선택된 탭은 해당 문서에만 적용되며, 확인되지 않은 문서는 검토로 시작됩니다.

2026년 9월 14일

파일명에서 확장 명이 제거됩니다. 목록과 창에는 "청구서"라고 표시되고 "청구서.pdf" 대신에 표시됩니다. 계정 설정에서 이를 비활성화할 수 있으며, 저장된 파일 이름은 변경되지 않고 다운로드된 파일은 여전히 확장 명을 포함합니다.

새로운 PDF 미리보기. 저희가 직접 그리기 때문에 모바일에서도 작동합니다 — 이전에는 아이폰에서는 첫 페이지만, 안드로이드에서는 아무것도 보이지 않았습니다. 두 손가락으로 확대 가능하며 텍스트 검색 및 페이지 미리보기가 추가되었습니다.

PDF로 내보내기 및 전체 ZUGFeRD. 읽을 수 있는 PDF 청구서와 XML이 삽입된 PDF/A-3 형식의 ZUGFeRD이다; 이전에는 원시 XML만 반환되었습니다. 기존 ZUGFeRD 형식은 XML로 유지되어 웹훅과 API 클라이언트가 중단되지 않도록 합니다.

결과는 원할 때 생성됩니다. 전환 수정을 통해 이전 문서에도 전파됩니다: 청구서를 다시 다운로드하면 최신 형식으로 받게 됩니다. 모델이 다시 호출되지 않으며, 크레딧도 소모되지 않습니다.

2026년 9월 13일

사용자 정의 문서 이름. 창의 상단에는 연필이 있는 필드가 있어 문서의 이름을 자유롭게 설정할 수 있습니다. 파일 이름은 아래에 유지되며 두 이름 모두에서 검색됩니다.

VIES 등록부에 대한 DIČ 검증. 공급자 및 수령자의 DIČ는 유럽연합 세금 등록부에서 검증됩니다. 이는 비용이 들지 않으며 저희 서버가 조회하며, 귀하의 브라우저는 아닙니다.

방향, 유형 및 중복 해결 버튼. 발견사항에 대해 해결해야 할 것을 알고 있는 경우 버튼이 나타납니다. 문서 방향에 대해 변경하거나 공급자와 수령자를 바꿀 수 있는 제안이 표시되며 — 이는 원본을 보고 판단됩니다.

보고서: 빠른 선택 "무엇 × 언제". 이전에는 한 가지 선택 항목으로 채권과 채무가 혼합되어 하나의 금액으로 표시되었습니다. 현재는 무엇(채권, 채무, 연료)과 어떤 기간에 대한 선택이 개별적으로 이루어집니다.

보고서의 기간은 발행일 기준입니다. 즉, 업로드 일자가 아니라, 예를 들어 9월에 업로드된 8월 청구서가 이전에는 9월로 간주되었습니다.

문서의 발행일에 따른 ČNB 환율. 모든 항목을 동일한 현재 환율로 계산하므로 작년의 유로 청구서가 올해의 환율로 계산되었습니다. 환율은 이력을 포함하여 저장되며, 각 문서는 발행일에 해당하는 환율로 재계산됩니다.

문서가 아닌 파일. 실수로 업로드된 광고는 항목에서 이점이 있는 청구서로 통과되었습니다. 이제 인식 시스템은 이를 문서가 아니라고 응답할 수 있으며, 파일은 데이터 추출 전에 인식되지 않은 상태로 마감됩니다.

전자 청구서의 크레딧 가격. ISDOC 또는 ZUGFeRD로부터의 문서의 0은 이제 "모델 없이 로드됨, 무료"를 의미하며, 더 이상 "가격 불명"을 의미하지 않습니다.

2026년 9월 11일

완료된 문서에도 양식 사용. 듀얼 미리보기 모드에서 형식 / 데이터 전환기가 있어 인식된 데이터가 필드 및 레이블 표시와 함께 JSON 또는 XML이 아닌 형식으로 읽힙니다.

라벨 및 바인더 색상. 라벨과 바인더를 선택할 수 있는 팔레트가 제공되어 밝은 테마와 어두운 테마 모두에서 읽을 수 있습니다. 이전에는 색상이 이름에서 유래되어 라벨 간의 식별만 가능했습니다.

검토 대기 이유를 출력에서 직접 확인. 아이콘 위의 버블에서 발견사항을 이전 검토와 같은 문장으로 표시합니다. 빈 목록은 문서가 정상이며 계정 설정을 요청한다는 의미입니다.

점유된 공간 구성을 설명합니다. 아이콘 아래의 버블은 몇 개의 문서가 있으며 그 중 얼마나 많은 문서가 휴지통에 있는지, 평균 크기 및 가장 큰 파일 크기를 표시합니다. 휴지통은 고대부터 점유된 크기에 포함되며 — 삭제된 문서는 여전히 저장소에 존재하며 — 이제는 인터페이스에서 확인할 수 있습니다.

남은 기간은 개월 및 연도로 표시됩니다. "3650일 남음" 대신 남은 기간의 끝이 얼마나 먼지를 기반으로 단위가 표시됩니다.

업로드 후 통과하지 않은 파일만 목록에 남습니다. 20개의 초록 체크 마크는 아무도 읽지 않고 그 사이에 있는 빨간 줄이 사라집니다. 얼마나 많은 문서가 통과했는지는 메시지로 안내됩니다.

계정 전환 후 외부 문서. 로그아웃한 사용자가 곧바로 예시 계정에 들어가면 여전히 자신의 문서를 볼 수 있었으며, 페이지 메모리에 data가 남았습니다. 이제 계정 변경 시마다 메모리가 지워집니다.

메시지, 창 및 패널이 하나의 규칙에 따릅니다. 발생하고 사라진 사건에 대해서는 상단의 메시지로 표시됩니다. 이제 막 발생하려고 하는 사건은 결정을 요구하며, 현재 보고 있는 내용에 적용되는 사항은 그 내용의 패널에 표시됩니다.

2026년 9월 10일

다섯 개의 회계 시스템으로 전송됩니다. Fakturoid, iDoklad, SuperFaktura, Xero 및 QuickBooks, 각각 자신의 제작자 라이브러리에 걸쳐 있으며 전체 선택을 대량으로 전송할 수 있습니다. 설정은 설정 → 연결에서 조정됩니다.

전체 목록 다운로드가 목록으로 이동했습니다. 플로팅 바는 선택 항목에 속하며, 필터를 통과한 모든 것을 다운로드하는 것은 테이블 헤더에 있으며, 그와 관련된 곳에 있습니다.

세 가지 열로 구성된 목록 필터는 해당 문서에 대해 자주 고민하는 질문을 기반으로 구성됩니다: 어떤 유형의 문서인지, 어떤 기간인지, 어디에 분류했는지.

열려 있는 창이 문서가 완료되었음을 인식합니다. 대기열에서 문서를 열고 그 문서에서 몇 분을 기다리면 "처리 중 대기"라는 메시지가 여전히 나타났습니다.

항목 간 요약 행은 스스로 제거됩니다. "총계" 항목이 항목으로 복사되면 문서가 두 배가 되며 회계로는 추가 항목으로 발송됩니다.

2026년 9월 8일

폴더를 업로드할 때 선택합니다. 목록 아래 탭은 필터처럼 보였으나 필터가 아닙니다. 이는 첫 번째 업로드 양식의 필드가 되어, 그로부터의 선택이 이루어집니다.

문서 식별자에 따른 검색. API 응답의 ID 시작 부분만으로 동일한 항목을 검색할 수 있습니다.

라벨과 바인더를 첫눈에 구분할 수 있습니다. 이전에는 두 개의 분류가 동일한 아이콘을 가지고 있었습니다. 라벨들은 예전 색상을 유지하고, 바인더는 중립 색상과 폴더 아이콘만 남았습니다.

CodeMirror에서 사용자 정의 스키마 에디터. 기존의 에디터는 외부 CDN에서 실행 중 다운로드 되어, 없이는 로드되지 않았습니다.

활동 기록이 제대로 된 감사 로그로. "이메일 수신 및 1 문서 생성"이라는 기록은 어떤 이메일인지, 누구인지 알지 못했습니다. 이제 사건은 실제 발생한 내용을 담습니다.

"문서 유형"이 더 이상 두 가지 의미가 아닙니다. 필터 및 세부정보에서 문서의 방향은 문서 유형으로 명기됐으나, 이는 스키마 선택을 나타내는 동일한 단어였습니다. 이제는 문서 방향으로 변경되었으며 유형별로 필터가 추가되었습니다.

연료 영수증이 Pohoda 및 Money S3로 지급 문서가 아니라 청구서로 처리됩니다. 10,000 Kč 이하의 경우 간소화된 세금 문서로 간주되며 청구서 목록에는 포함되지 않습니다.

내보내기는 제조업체의 공식 XSD에 대해 검증됩니다. 이를 통해 문서가 올바르게 보였으나 회계로 가져올 때 깨진 경우가 있을 수 있습니다.

보안: API 키가 더 이상 수신 주소를 관리하지 않습니다. 문서 업로드용 키는 수신을 위한 이메일 주소를 만들 수 있었고 허용된 발신자 사이에 누구든지 추가할 수 있었습니다. 이제 이러한 엔드포인트는 로그인 된 계정에만 속합니다.

2026년 9월 7일

시스템 스키마. 저희가 제공하는 스키마는 여러분의 스키마 위에만 존재하는 고유 그룹입니다. 읽기 전용이며 문서는 어떤 스키마로 추출되었는지 기억합니다 — 이전의 것은 에디터로의 일회성 복사였습니다. 이들 사이에는 연료 영수증이 포함됩니다.

바인더가 선택 항목을 미리 채웁니다. 문서 유형, 출력 형식, 방향 및 회계 화폐는 바인더에 저장되고 업로드 시 이전됩니다.

추출된 데이터에 대한 보고서. 기간, 통화 및 문서 유형에 따른 합계입니다.

클라우드 형식의 필드 명 수정. 문서 및 SDK 문서와 대조를 통해 6개의 오류가 발견되었으며, 일부는 청구서의 숫자를 변경했습니다 — 예를 들어 iDoklad의 경우 세금 포함 가격을 의미하지만 세금 없이 전송됩니다.

2026년 9월 4일

네 가지 출력 형식 대신 여섯 개의 형식. 네 개의 클라우드 회계와 세 가지 유럽 전자 청구서 형식(Peppol BIS 3.0, XRechnung 3.0, ZUGFeRD / Factur-X) 및 이전의 이진 Excel이 추가되었습니다.

문서 방향. 모든 이전 전환은 채무 측으로 진행되어, 자체 발행 청구서가 채권이 아닌 채무로 회계 처리되었습니다. 방향은 업로드 시 선택됩니다.

추출된 데이터에서 수령자. 이전에는 전자청구서 형식에 대체 값을 대입했습니다.

회계 단위 통화. Pohoda는 회계 단위에 따라 국내 및 외국 통화를 구분하며 슬로바키아의 Pohoda는 유로를 사용합니다. 업로드 시 선택해야 하며, 하나의 회계 계정이 여러 국가의 회사들을 운영할 수 있기 때문입니다.

다페이지 문서 전체 처리. 이전에 모든 크레딧이 공제되었음에도 불구하고 첫 페이지만 처리되었습니다. 최대 20페이지까지 허용되며 업로드 시에 이미 제한됩니다.

사용자 정의 스키마에 대한 템플릿. 비어 있는 페이지 대신 다섯 개의 템플릿이 존재합니다.

문서 목록에 포함된 형식. 테이블이 이를 표시하지 않았지만 애플리케이션은 이를 인식했습니다.

배포된 버전의 XLS 내보내기 작동하지 않음. 오류 메시지를 반환했으며, 개발 컴퓨터에서 이것을 확인할 수 없었습니다.

모든 엔드포인트에 대한 보안 감사. 세 가지 발견 중 가장 심각한 문제는 서버가 주어진 모든 주소로 웹 훅을 전송했던 점이며, 내부 네트워크 주소도 포함되었습니다.