<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="/feed.xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>OCR on CFOzine（シーエフオージン）｜CFO・経理財務のための実務メディア</title>
    <link>https://cfozine.jp/tags/ocr/</link>
    <description>Recent content in OCR on CFOzine（シーエフオージン）｜CFO・経理財務のための実務メディア</description>
    <image>
      <title>CFOzine（シーエフオージン）｜CFO・経理財務のための実務メディア</title>
      <url>https://cfozine.jp/og-default.png</url>
      <link>https://cfozine.jp/og-default.png</link>
    </image>
    <generator>Hugo</generator>
    <language>ja-jp</language>
    <copyright>2026 CFOzine ・ 運営: Never Red株式会社</copyright>
    <lastBuildDate>Wed, 19 Aug 2026 06:44:37 +0900</lastBuildDate>
    <atom:link href="https://cfozine.jp/tags/ocr/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>請求書のOCR自動化はどこで止まるか｜三面照合と例外処理をERPのどちら側に置くか</title>
      <link>https://cfozine.jp/posts/ap-invoice-ocr-three-way-match/</link>
      <pubDate>Wed, 19 Aug 2026 06:44:37 +0900</pubDate>
      <guid>https://cfozine.jp/posts/ap-invoice-ocr-three-way-match/</guid>
      <description>項目精度99%は伝票精度99%ではない。1枚あたり10項目なら全項目正解は90.4%、明細行が増えて100項目になれば36.6%に落ちる。だが支払業務が詰まる本当の理由は読み取りでなく、発注・検収との照合が合わない例外である。SAPのロジスティクス請求書照合は許容差異キーを会社コード単位で設定し、上限超過でブロック、解除はMRBRという工程を持つ。この照合と例外をERPの外側に置くと、発注残と入庫データの鮮度差で差戻しが増える。OCRは入力の代替に限定する。</description>
    </item>
  </channel>
</rss>
