ニュース

アプリケーションで何が変わったのか、それがあなたにとって何を意味するのか。最新の情報が上にあります。

ここには、実際に作業を行う際にわかるものだけが記載されています: 新機能、動作の変更、修正。新しい記録が追加されると、ヘルプ タブに点が表示され、あなたがこのページを開くと消えます。

アプリケーションは継続的にデプロイされているため、リリースにはバージョン番号がなく、日付だけが記載されています。

2026年9月18日

割引後の価格、割引前は含まれません。 行に対して、割引前と割引後の価格が印刷される場合 — ハイパーマーケットのレシートや建材の請求書 — 割引後の価格が抽出されます。以前は、最初に出てきた価格がデータに入っていましたので、実際に支払った金額よりも高いコストが計上されていました。

アイテム税率に対する新しいチェック。 ルーブルで発行された外国の請求書には、自国通貨の税金が列に表示され、見た目にはすべてが正しいように見えます: 基本額 ＋ 税金 が支払額になりますが、行の税率がそれを証明します。今、そのような請求書には検出結果が表示されます。修正ボタンは故意に含まれていません — 税金と共に、支払額にも間違いがあるため、両方のフィールドを一度に修正する必要がある請求書は人間にしか適用されません。

税率の代わりに記入された税額が修正されます。 ドイツの請求書には「MwSt」列にユーロで記載された税額があり、率には例えば19.84%が入ることがあります。このような税率がEUのどこでも通用しない場合にのみ修正され、金額を読んだ後に実際に存在する税率が表示され、計算された税金は請求書の再集計に適用されます。

外国のVAT率はもはや検出結果ではありません。 ポーランドの23%、オーストリアの20%、ポルトガルの6%は以前は異常な率として通知されていました。国内の請求書は発行日の日本の税率で測定されます。

アイテムに欠落した税率が補充されます。 割引、四捨五入、または前受金の控除がある場合、税率の列はダッシュになります。そのような行は以前はゼロ税率にカウントされ、再集計が請求書に記載されているものと一致しませんでした。税率は合計が確認されたときのみ補充されます。

税金を含む価格のアイテムが再計算されます。 請求書では、行の価格は税抜きで、モデルが税金を含む金額を取得していた場合、会計には引き上げられた基本額が記録されていました。92件の請求書のサンプルのうち、これに関係するのは15件でした。以前に処理された請求書は新しい処理やクレジットなしで遡って再計算されました。

メールのアップロード（.eml）。 保存されたメッセージをアップロードすると、その添付ファイルから請求書が作成されます。請求書が作成されなかった添付ファイルについては、その理由がわかります。

IČO（法人識別番号）が同じ側のDIČ（付加価値税識別番号）と比較されます。 チェコの企業のDIČにはそのIČOが含まれているため、両方の番号が同じ企業に属するかを確認できます。見積もりでの販売業者と購入者の入れ替えを見つけますが、チェック桁では難しい — 両方の番号は有効ですが、別の誰かに帰属しています。この検出に対する修正は一回のクリックで提案されます。

2026年9月17日

請求書が二重に処理されません。 キューが同じ作業を二度配送した場合、二度目の試みは中止されます。誰かももっと作業を続けている請求書は、10分後に待機の列に戻ります。

WebhookとTelegramへのメッセージは請求書が保存された後のみ送信されます。 処理の終了と保存の間の短い瞬間に、Webhookが全く送信されなかったり、失敗した請求書に対して「完了」と報告されたりすることがありました。

2026年9月16日

モデルの請求書の限度額が下がらなくなります。 大量データ処理の後、1日の限度額を超える請求書がエラーとして記録されていました。今は、キューで待機し、限度が解放され次第処理されます — エラーメッセージもなく、クレジットが行き来することもありません。

大量のデータ処理は他をブロックしません。 キューは顧客を切り替えているため、千の請求書のインポートは、同時に誰かによって別の請求書がアップされても停止することはありません。

より正確なデータ抽出。 データ抽出が新しいモデルに移行しました: 検証セットでの正しいフィールドの割合は98.4%で、これまでの88.0%と比較されてます。ばらばらのハックと商品コードのゼロとOの置き換えが消えました。

デジタルPDFはテキストレイヤからも読み取られます。 ページ画像の隣にファイルのテキストが抽出されるため、画像で誤解される可能性のあるものも読み取られます。サンプルでの精度は98.4%から100%に上昇しました。

チェコの企業のIČOは8桁である必要があります。 割り当てのない桁は以前は考慮されておらず、外国の登録番号が無駄な検出を受けることがないようにしていました。チェコの企業であるかは、同じ側のDIČが示します。

検出結果のある請求書の確認には意識的な承認が必要です。 検出結果のある請求書はそのままでは通過しません: 検出結果はウィンドウに表示され、そのまま承認ボタンで確認されます。二つのゼロなしの見落とされたIBANは他のフィールドの修正に埋もれません。

プレビューの検索はデータ内も探します。 左側のオリジナルで見つけたものは右側でもハイライトされ、フォームと結果の中でも表示されます。請求書から転記された金額（「16 591,56」）は、JSONやXMLでも対応するものを見つけます。

処理は専用のサービスで実行されます。 新しいバージョンのデプロイにより、未処理の請求書の中断がなくなりました。

2026年9月15日

完了した請求書を修正します。 ウィンドウのヘッダーには二つの経路を持つボタンがあります: データをチェックに戻して修正する（これは無料です）か、別のタイプで再処理するか。以前は不良請求書に対しては削除して再アップロードする以外何もできませんでした。

一般的なレシートを新しい請求書タイプとして。 レストランのレシートは以前は燃料のレシートとして通過することができましたが、請求書と燃料の間でしか選択できなかったためです。一般的なレシート用のスキーマが追加され、燃料レシートに燃料がない場合は、それを検出します。

ISDOCに対するレシート は、従来のPohodaとMoney S3の簡易税務書類として。

公式のスキーマ 6.0.2 に基づくISDOC。 従来のスキーマ出力は基準に合わず、請求書の半分が欠けていました。現在は自動的にそれに対して確認されます。

選択された請求書タイプに合わない形式はどこでも生成されません。 そのような変換をダウンロードすることは拒否されましたが、詳細、プレビュー、Webhook、MCPがそれを生成しました。現在、どこでも同じエラーメッセージが返されます。

請求書のアイテムにVATなしの請求書には合計がアイテムにありません。 非課税請求書からの請求書では時折中間合計、合計、支払額が分解に入り、実際の金額の倍数になってしまうことがありました。

確認後に次の請求書が開かれます。 前はウィンドウは確認された請求書に留まり、次の請求書に行くには表示の間にあるものを矢印で訪れる必要がありました。

矢印での移動はデフォルトタブを開きます。 選択されたタブは選択が行われた請求書に対してのみ有効であり、未確認の請求書ではチェックから始まります。

2026年9月14日

拡張子なしの請求書の名前。 リストおよびウィンドウは「請求書」と表示され、や「請求書.pdf」とは表示されません。これをアカウント設定でオフにすることができ、保存されたファイル名は変更されず、ダウンロードされたファイルはそのまま拡張子を持ち続けます。

新しいPDFプレビュー。 私たちが作成しているので、モバイルでも動作します — iPhoneでは以前はプレビューで最初のページしか表示されず、Androidでは何も表示されませんでした。二本指でのズーム、テキスト内の検索、ページプレビューが追加されました。

PDFエクスポートと完全なZUGFeRD。 読むための請求書としてPDFで、ZUGFeRDはXMLを埋め込んだPDF/A-3として; それ以前は生のXMLのみが返されていました。従来のZUGFeRD形式はXMLのままとし、WebhookやAPIクライアントが壊れないようにしています。

結果は、あなたが望んだときにのみ生成されます。 変換の修正は古い請求書にも反映され、再度請求書をダウンロードすると現在の形で受け取ります。モデルは再呼び出しされず、クレジットはかかりません。

2026年9月13日

独自の請求書名。 ウィンドウのヘッダーには鉛筆アイコンのフィールドがあり、自分の名前を請求書に付けることができます。ファイル名はその下に残り、両方の中で検索されます。

DIČをVIESレジストリと照合します。 供給者と顧客のDIČが欧州委員会のVAT納税者登録簿で確認されます。費用はかからず、私たちのサーバーが問い合わせを行います。

方向、種別、重複を解決するためのボタン。 私たちが何をするか知っている検出結果がある場合は、ボタンが存在します。請求書の方向に基づいて方向の変更や供給者と顧客の入れ替えが提案されます — 原本に基づいて決まります。

概要: 何と いつの迅速な選択。 一連の選択肢は以前は債権と負債を一つの金額に混合していました。今は特に何（債権、負債、燃料）を選択し、別々にどの期間について選択するか注明できます。

概要の期間は発行日の基準に基づき、 アップロード日ではありません。8月の請求書が9月にアップロードされた場合、その請求書は以前は9月に属していました。

請求書の日付のCNBの為替レート。 一つの通貨に換算するために、すべてに今日の為替レートが適用されていましたので、前年のユーロ請求書は今年のレートで計算されていました。為替レートは履歴と共に保存され、各請求書は発行日の為替レートで再計算されます。

請求書でないファイル。 誤ってアップロードされた広告は、アイテムに特典がある請求書として処理されました。認識は今やそれが請求書でないことを返答でき、ファイルは抽出される前に認識されないまま終了します。

電子請求書におけるクレジットの価格。 ISDOCまたはZUGFeRDからの請求書でのゼロは「モデル無しで読み取り、無料」を意味し、「価格が不明」を意味しません。

2026年9月11日

完了した請求書にもフォームが表示されます。 デュアルプレビューにはフォーム / データのスイッチがあり、認識されたデータはフィールドとラベルごとに読み取られ、単なるJSONやXMLとしてではなくなります。

ラベルとフォルダーの色。 明るいテーマと暗いテーマの両方で読みやすいパレットから選択されます。以前は名前から色が導出され、ラベルを区別することだけができました。

請求書がなぜチェックを待っているのか、明示的にリストに表示されます。 バッジの上のバブルが、フォームにある検出結果と同じ文で表示されます。空のリストは、請求書が正常であり、アカウント設定が確認を要求していることを示します。

占有された場所の構成要素。 バッジのバブルが、いくつの請求書が存在し、どれがゴミ箱にあり、サイズ、平均サイズ、最大ファイルサイズが表示されます。ゴミ箱は常に占有にカウントされます — 削除された請求書はストレージ内にそのまま残ります — それがインターフェースで見えるようになりました。

残りの期間（月数および年数）。 「3650日残っている」ではなく、期限の終わりまでどれくらい残っているかで表示されます。

アップロード後、リストには通過しなかったファイルのみが残ります。 20の緑のチェックマークは誰も読みませんし、その中の1つの赤い行が埋もれてしまいます。いくつの請求書が通過したかはメッセージが教えます。

アカウント切り替え後の外国請求書。 サインアウトしてからそのままサンプルアカウントにログインすると、しばらくは自分の請求書がまだ表示されていました: データがページのメモリに残っていました。アカウントを切り替えるたびにメモリがクリアされます。

メッセージ、ウィンドウ、パネルは一つのルールに基づく。 何が起こったか、そしてなくなったかは、一番上のメッセージが伝えます。何がこれから起こるか、決める必要があるかは、ウィンドウが尋ねます。現在見ているものに関して適用されることは、そのコンテンツに関するパネルに残ります。

2026年9月10日

5つの会計システムへの送信。 Fakturoid, iDoklad, SuperFaktura, Xero,そしてQuickBooks、それぞれがその作成者のライブラリで、選択した全体を一括送信することができます。設定は設定 → 接続で行います。

全体のレポートのダウンロードがレポートの近くに移動しました。 下のフローティングバーは選択に属し、フィルターに通過したものすべてをダウンロードするのはテーブルのヘッダーで行います。

レポートのフィルターは3つの列 に基づいて、誰もが自分に問いかける質問に従っています: それは何の請求書で、いつのものか、どこに分類したのか。

開いているウィンドウは、請求書が完成したことを知ります。 キューの中で請求書を開いてそのまま待っていると、「処理中を待っています」と何時間も表示し続けていました。

アイテム間の合計行が自動的に削除されます。 アイテムに書き込まれた「合計」としての行は、請求書の分解を2倍にし、会計には余分なアイテムとして送信されます。

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日

4つの出力形式から16種類に。 4つのクラウド会計と3つのヨーロッパの電子請求書形式（Peppol BIS 3.0, XRechnung 3.0, ZUGFeRD / Factur-X）および古いバイナリExcelが追加されました。

請求書の方向。 すべての転送は以前は負債の側に向けられており、自発的に発行された請求書が債権ではなく負債として記入されていました。方向はアップロード時に選択されます。

抽出時の受取人。 以前は電子請求書形式に代理値が設定されていました。

会計単位の通貨。 Pohodaは国内通貨と外国通貨を会計単位に基づいて区別し、スロバキアのPohodaはユーロを扱います。アップロード時に選択されます; 一つのアカウントで複数の国の企業を扱うことができます。

複数ページの請求書全体。 最初のページのみが処理されていましたが、クレジットは全てのページに対して差し引かれていました。上限は20ページで、アップロード時に確認されます。

カスタムスキーマのためのテンプレート。 空白のページの代わりに5つのテンプレート。

請求書の出力形式の表示。 テーブルはそれを表示していませんでしたが、アプリケーションは知っていました。

デプロイ版のXLSへのエクスポートは機能しませんでした。 ファイルの代わりにエラーメッセージを返し、開発用コンピュータではそれを見つけることができませんでした。

すべてのエンドポイントのセキュリティ監査。 3つの検出結果の中で最も重大なものは、サーバーが受信したどんなアドレスに対してもWebhookを送信していたことに関するもので、内部ネットワークのアドレスも含まれていました。