발견 및 해결 방법

발견은 문서에서 잘못된 점에 대한 설명입니다. 발견 수치는 클라이언트가 아니라 서버가 계산하므로, 양식에서 생성된 문서에도 API를 통해 전송된 문서에도 동일하게 발생하며, API 클라이언트는 데이터를 함께 받습니다.

발견의 종류

각 검토는 설정에서 끌 수 있습니다. 꺼지면 전혀 계산되지 않으며 이를 기준으로 문서가 검토 대기열에 놓이지도 않습니다.

발견으로 인해 발생하지 않는 것

발견은 결코 자동으로 수정되지 않습니다. 계산이 가능한 경우 수정하기라는 버튼이 제안되며, 해당 값은 사용자가 입력해야 합니다. IČO의 경우, 체크디지트만 확인할 수 있을 때 제안이 나타나지 않습니다. 이 숫자는 대략 매 11번째 임의의 숫자를 통과시키므로, 자동 수정을 통해 유효하지만 다른 IČO가 생성될 수 있습니다. 이러한 오류는 가시적인 비논리적 오류보다 더 나쁩니다. 왜냐하면 아무도 그것을 인식하지 못하기 때문입니다.

유일한 예외는 문서에 DIČ도 있는 회사입니다. 회사의 세금 번호는 CZ와 해당 IČO이며, 따라서 올바른 값이 문서에서 인접해 있기 때문에 별도의 계산 없이 제안됩니다 — 이 경우 제안이 제공됩니다. 자영업자의 경우, DIČ는 개인 식별 번호이므로, 이 경우 IČO와 DIČ를 전혀 비교하지 않습니다.

제안이 나타나지 않는 경우는 문서에 값을 삽입할 경우 자기 모순이 발생할 수 있는 곳입니다. 항목의 합계가 세금 기준과 세금을 더하여 총 금액을 발생시키는 문서의 경우, 합계를 삽입하면 그 관계가 무너지므로 — 발견은 그대로 유지되지만 값은 제안되지 않습니다.

중복 항목

다중 페이지 문서에서 동일한 항목이 다른 제목 아래 두 번 나열될 수 있습니다: 클라우드 청구서는 서비스에 대한 요약과 그 이후의 계좌에 대한 요약을 갖고, 통신사 청구서는 서비스와 전화번호에 대한 요약을 갖고 있습니다. 모델은 두 개의 표를 수신하여 각 항목을 읽으므로 데이터에 각 항목이 두 번 존재하며, 합계는 두 배가 되고 회계는 두 번 진행됩니다.

발견은 모든 항목이 동일한 횟수로 반복되고, 다양한 항목이 최소 세 개 이상일 때만 발생합니다. 하나의 항목 추가 또는 누락으로 인해 발견은 발생하지 않으며 — 동일한 쌍이 하나의 문서에 두 개 존재하는 것은 일반적이며, 이들 때문에 목록의 절반을 삭제하는 것은 침묵하는 것보다 더 나쁠 것입니다.

발견이 표시되면, 각 세트에서 첫 번째 발생을 유지하고 나머지를 삭제하는 버튼이 있습니다. 전체 목록이 한 번에 변경되며, 하나씩 삭제하면 라인 번호가 바뀌기 때문입니다. 요약에는 영향을 미치지 않습니다: 세금 기준, 세금 또는 총 금액이 변하지 않으며, 그것들은 문서에서 유효합니다.

해외 청구서의 경우, 항목들이 요약과 다른 통화로 되어 있으니 주의하시기 바랍니다. 클라우드 청구서는 달러로 청구하고 요약만 유로 또는 코루나로 환산합니다. 따라서 이런 문서의 중복 항목 정리를 통해서는 완벽하게 수정되지 않습니다: 항목의 합계와 총합이 다른 통화에 있기 때문에 맞지 않습니다. 그러한 문서에서는 청구서 전체에 대해 하나의 항목을 남기는 것이 더 효율적입니다.

요약과 다른 통화의 항목

해외 청구서가 클라우드에서 달러로 청구되며 통화로는 합계만 환산됩니다: 서비스의 세부사항은 USD로 남아 있고, 세금 기준 및 지급 금액은 유로 또는 코루나로 되어 있습니다. 문서는 애플리케이션에서 단일 통화를 가지고 있기 때문에, 항목과 세금 기준의 합계가 맞지 않습니다. 그 어떤 것이 수정되더라도 변하지 않습니다.

이것은 각 금액 옆에 통화가 명시된 문서 전사에서 확인할 수 있습니다. 전사가 없는 문서 — 전자 청구서 또는 OCR이 비활성화된 경우 — 에서는 검토가 작동하지 않으며 단순한 발견만 유효합니다.

발견이 발생하기 위해서는 외환이 적어도 세 가지 다양한 항목 가격에 있어야 하며, 문서에는 통화가 나타나지 않아야 합니다. 각 행에 두 개의 통화를 인쇄하는 문서는 단순히 환산일 뿐이며, 발견을 생성하지 않습니다.

애플리케이션은 수정 제안을 제공하지 않습니다. 왜냐하면 올바른 응답이 문서에서 유도되지 않기 때문입니다. 두 가지 선택이 있습니다:

1. 문서의 통화 및 항목을 단순화하여 하나로 설정합니다, 예를 들어 서비스 8/2026의 세금 기준 금액. 회계에서 실제 지급되는 금액이 반영되어, 서비스에 대한 세부사항이 원본 상태로 문서에 보관됩니다. 이는 회계에 가장 깔끔한 방법입니다.
2. 문서를 항목의 통화로 변환하여 요약과 함께 진행합니다. 그 경우 문서 내부에서 일치하지만, 지급 금액과 세금이 실제 지급되는 통화와는 다른 통화로 표시됩니다 — 부가세 신고서에는 문서의 금액이 포함됩니다.

발견을 그대로 두고 문서를 확인할 수도 있습니다. 그렇게 되면 회계는 한 통화로 항목을, 다른 통화로 요약을 처리하게 되며, 프로그램은 문서에 기록된 내용과는 다른 수치를 산출합니다.

그러한 문서에 대해 항목 합계 검토는 진행되지 않습니다. 합계가 맞지 않을 수 없으며, 동일한 문제에 대한 두 번째 알림은 새로운 정보를 제공하지 않습니다.

발견을 마무리하는 방법

두 가지 방법이 있습니다:

1. 값을 수정합니다. 발견은 다시 계산이 완료됨과 함께 자동으로 사라집니다.
2. 그대로 둡니다. 값이 올바르고 발견이 허위인 경우 — 예를 들어, 다른 부가세 비율을 가진 해외 공급업체. 확인할 때 남아 있는 발견 목록이 표시되며, 여러분은 이를 한 번에 확인합니다. 창을 보지 않고 싶다면 다시 나타내지 않기를 확인하십시오; 설정에서 다시 활성화할 수 있습니다.

활동 기록에는 문서를 확인한 사람과 데이터에 손댔는지 여부가 기록됩니다.

공급업체 계좌

청구서와 관련된 가장 흔한 사기는 다음과 같이 발생합니다: 아는 공급업체로부터 청구서가 오며, 평소와 다름없이 모든 것이 동일하지만 계좌 번호가 다릅니다. 체크합계는 이를 인식하지 못합니다. 왜냐하면 위조된 계좌는 유효할 수 있기 때문입니다.

그래서 애플리케이션은 각 공급업체에 대해 여러분이 지급했던 계좌를 기억하고, 문서에 다른 계좌가 있는 경우 이를 발견으로 알립니다. 이건 블로킹이 아닙니다: 계좌는 실제로 변경되며 문서는 있는 그대로 회계에 기입되어야 합니다. 발견은 다른 발견과 마찬가지로 확인할 때 동의하면 됩니다. 그 이후로는 새로운 계좌도 알려집니다.

중요한 점은 다음과 같습니다:

• 계좌는 검토 승인 시 기억됩니다. 인식으로는 기억되지 않습니다. 만약 인식이 충분했다면, 위조된 청구서가 스스로 계좌를 등록했을 것입니다. 누군가 이를 열기 전에 먼저 등록되었을 것입니다.
• 공급업체의 첫 청구서는 아무것도 보고하지 않습니다. 비교할 것이 없으므로, 기본값만 설정합니다. 은행에서도 동일합니다.
• 국내 기록과 IBAN이 동일한 계좌입니다. 하나의 청구서에는 19-2000145399/0800을, 다른 하나에는 CZ6508000000192000145399을 기록합니다. 이로 인해 발견이 생성되지 않습니다.
• 보낸 청구서에는 적용되지 않습니다. 발행된 청구서에는 여러분 자신의 계좌가 기록됩니다.
• 발견은 수정을 제안하지 않습니다. 종이에 있는 대신 기억된 계좌로 대체하는 것은 "청구서가 말하는 것과는 다른 곳으로 결제하세요"라는 버튼 같습니다. 이를 결정하는 것은 여러분이며, 청구서가 아닌 곳에서 새로운 계좌를 반드시 확인해야 합니다.
• 알려진 계좌는 거래상대에게 표시됩니다. 공급업체 세부정보의 거래상대 탭에서 확인할 수 있으며, 마지막으로 확인한 사람도 함께 나타납니다. 여기에 공급업체의 기억을 지울 수도 있습니다.

DIČ 및 납세자 등록

공급업체 및 고객의 DIČ는 유럽 VIES 레지스터에서 확인됩니다. 레지스터가 현재 응답하지 않는 경우, 발견은 발생하지 않습니다 — 브뤼셀의 문제로 공급업체에게 전화할 필요가 없습니다. 국가 접두사가 있는 유럽 DIČ만 확인됩니다.

여러분의 DIČ는 확인되지 않습니다. 자신의 납세자를 알고 있습니다. 또한, 부가세를 포함하지 않는 청구서의 공급업체의 체코 DIČ도 확인되지 않습니다: 비납세자는 DIČ를 가질 수 있지만, 납세자 등록부에는 없습니다.

VIES 레지스터는 단순히 예/아니오만 반환하며, 기업 이름과 비교하지 않습니다. ARES 등록부는 다른 곳에서 사용됩니다 — 설정에서 귀하의 회사를 기입할 때 사용됩니다.