完成の定義と受け入れ基準の違いは何ですか？

まずは完成の定義です。スクラムガイド2020では、完成の定義は以下のように記述されています。

完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。
開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。

ここでポイントになるのは「プロダクトの品質基準」という箇所です。プロダクトバックログアイテムが完成した、というからにはあらかじめプロダクトとして定めた品質を満たしている必要があるわけです。つまり完成の定義は、すべてのプロダクトバックログアイテムに対して共通して適用されます。内容としては、コードレビュー、静的解析やテストの実行範囲、ドキュメント、デプロイなどが含まれます。

次に受け入れ基準です。これはスクラムの正式な用語ではありません。

エクストリームプログラミングに由来するプラクティスの1つにユーザーストーリーがあります。ユーザーストーリーは要求を自然言語で簡潔に記述するためのフォーマットです。スクラムでもプロダクトバックログアイテムを記述するのによく使われます（がスクラムでは、プロダクトバックログアイテムのフォーマットは特に規定していないので、ユーザーストーリーを使わなければいけないわけではありません）。そして、会話を通じて何を完成させるのかの共通理解を形成していきますが、そのときに機能がどうなっていれば完成なのかを簡潔にまとめたものが受け入れ基準になります。これは、詳細な仕様書でもないですし、すべてのテストケースを記述したものでもありません。ユーザーストーリーを補完し、円滑に開発を進め、受け入れテストをしやすくするためのものです。つまり受け入れ基準は、プロダクトバックログアイテムごとに異なります。

なお、受け入れ基準はスクラムにおいて必須なわけではありません。重要なのはスクラムチームのなかでプロダクトバックログアイテムの中身についての共通理解が形成されていることです。