WooCommerceとQuickBooks Onlineを同期する方法（そして何が壊れるか）

WooCommerceの注文をQuickBooksに取り込むのは簡単な部分です。このガイドは、プラグインのリストには記載されていない部分、つまり帳簿と銀行口座を一致させることについてです。

---

QuickBooks Onlineファイルには1,400件の新しい請求書があり、そのすべてが正確です。

コネクタをインストールし、いくつかのフィールドをマッピングして、それが機能するのを見守りました。すべてのWooCommerce注文が、顧客名、品目、配送、税金とともにQBOに届きました。プラグインの機能ページにあるあらゆる基準において、あなたのWooCommerce QuickBooks連携は完了していました。

次に銀行フィードを開きました。Stripeは月曜日に6,782.40ドルを入金し、PayPalは水曜日に1,911ドルを振り込みました。そして、その1,400件の請求書のどれ一つとして、どちらの金額とも一致しません。QuickBooksは現在、数十件の未処理請求書に対して単一の入金を照合するように求めていますが、それらの合計はいずれも一致しません。

もしあなたがこの状況に陥ったことがあるなら、おそらくほとんどのストアオーナーがするように、プラグインをアンインストールし、CSVエクスポートに戻り、このカテゴリ全体が壊れていると結論付けたことでしょう。壊れてはいません。しかし、あなたに販売されたもの、つまり注文同期は、実際の С問題ではありませんでした。

実際の С問題は、WooCommerceとあなたの銀行口座が2つの異なる現実を記述しており、注文同期をどれだけ行ってもそれらを翻訳できないことです。この記事では、その理由を数値とともに説明し、実際に照合される設定について説明します。

---

WooCommerceとQuickBooksを連携させる3つの方法

大まかに言って、すべての Сアプローチは3つの Сバケットのいずれかに分類されます。

1. 公式QuickBooksコネクタ。 Intuit独自のコネクタ（古いOneSaasエンジンをベースに構築）は、WooCommerceの注文を請求書または売上伝票としてQBOにプッシュします。安価で、Intuitによってサポートされており、基本的な注文コピーに関しては謳い文句通りの機能を果たします。それが知っているのは注文、つまり顧客が購入したものとWooCommerceが請求した金額です。

2. 専用同期プラグイン。 MyWorks Syncのようなツールは、さらに深く掘り下げます：双方向同期、詳細なフィールドマッピング、在庫と顧客の同期、リアルタイムプッシュ。あなたのビジネスが個々の請求書で運営されている場合（卸売アカウント、B2B顧客、特定の個人に関連付けられた支払い）、その注文ごとの忠実度は本当に価値があり、MyWorksはその点で強力です。もしあなたがその С経路を検討しているなら、LedgerPort vs. MyWorksで詳細な比較記事を書いています。

3. 手動CSVエクスポート。 WooCommerceから注文をエクスポートし、スプレッドシートを処理し、手動でQBOに仕訳を入力します。完全な С制御、 Сソフトウェア Сコスト Сゼロ、そして Сボリューム Сに応じて С月に С2 Сから С8 С時間 Сかかります С— Сそれに С加えて С疲れた С人間 Сが С3 С時間 С目に С犯す Сあらゆる Сエラー Сも С含まれます。

方法	移動するもの	コスト	銀行口座と照合されますか？
QuickBooksコネクタ	注文 → 請求書/領収書	低い	単独では不可
同期プラグイン（例：MyWorks）	注文、顧客、在庫	$ – $$	Only with careful payout configuration
Manual CSV	Whatever you type	Your time	Only if you do the payout math yourself

Notice what all three have in common: they start from order data. And order data is only half the dataset you need.

---

注文レベルの同期がなぜ照合を妨げるのか

Here’s the structural problem, and it has nothing to do with which plugin you chose.

WooCommerce knows about orders: customer, items, totals, tax. It does not know what Stripe deducted in processing fees, when PayPal batched a payout, which refund from last week got netted against this week’s deposit, or what a chargeback fee did to Tuesday’s disbursement. That information lives with your payment gateways — a completely separate dataset, on a completely separate schedule.

Your bank feed, meanwhile, only ever sees the gateway’s side of the story: net deposits, batched on the gateway’s timeline. So when a sync tool copies orders into QBO, it’s faithfully recording a dataset your bank account will never confirm.

実践的な例

Say your store takes 96 orders over a weekend, totaling $7,200 gross. WooCommerce reports this as three separate days of sales, and your order-level sync creates 96 invoices in QBO.

On Monday, Stripe sends one payout:

Stripe payout — Monday	金額
Gross weekend sales (96 orders)	$7,200.00
Processing fees (2.9% + $0.30 × 96)	−$237.60
Refunds (2 orders from last week)	−$180.00
Net deposit to your bank	$6,782.40

QuickBooks now holds 96 invoices totaling $7,200, spread across Friday, Saturday, and Sunday. Your bank feed holds one Monday deposit of $6,782.40. The $237.60 in fees exists nowhere in your books. The $180 in refunds belongs to orders that aren’t even in this weekend’s data. There is no combination of those 96 invoices that equals that deposit — the math is unmatchable by construction.

Multiply by every payout, every gateway, every month. That’s how you end up with 1,400 pristine invoices and a bank feed that agrees with none of them.

[IMAGE: Diagram showing WooCommerce order data and Stripe payout data as two separate streams, with the bank feed only connected to the payout stream — and the gap where fees and refund timing live]

At this point most people conclude one of three things: some decide they need to hire a bookkeeper, some go back to spreadsheets, and some realize the problem is architectural and fix the architecture. This section is for the third group.

---

「オープンソースなんだから、無料プラグインで対応できるはずだ」

Let’s name the assumption directly, because it’s reasonable and it’s wrong.

WooCommerce is open-source, the ecosystem has a plugin for everything, and most of them are free or cheap. So the instinct is: a free plugin should handle QuickBooks too. And a free plugin can handle what plugins are good at — moving order data from one database to another. That part genuinely is a solved problem.

しかし、照合はデータ転送の問題ではありません。それは、金額（総額対純額）、タイミング（注文日対支払い日）、および範囲（今週末の注文対先週の返金）について意見が異なる2つのデータセット間の*照合*の問題です。プラグインは、注文をより速く移動したり、フィールドをより正確にマッピングしたりすることで、それを修正することはできません。あなたはそれを間違って設定しませんでしたし、プラグイン開発者もそうではありませんでした。ツールは、理解した問題を解決しました。あなたが実際に抱えている問題は、ツールのモデルよりも大きいのです。

---

機能するアーキテクチャ：クリアリング口座、日次サマリー、手数料明細

その修正は、会計士が何十年も使用してきた構造をゲートウェイに適用したものです。3つのコンポーネント：ゲートウェイごとの*クリアリング口座*、注文ごとの請求書ではなく*日次サマリー*、およびすべての支払いにおける*明示的な手数料行*。ここに、ステップバイステップの手動設定を示します。

1. 
   

   *各ゲートウェイのクリアリング口座を作成します。* QBOでは、*その他の流動資産*タイプの「Stripe Clearing」という口座、次に「PayPal Clearing」という口座、さらに追加のゲートウェイごとに1つ追加します。この口座は、顧客が支払ったがまだあなたの銀行に届いていないお金を表します。まさにそれなのです。

   
   
2. 
   

   *個々の請求書ではなく、日次売上サマリーを投稿します。* 1日1回、ゲートウェイごとに1つのエントリを記録します：総売上、割引、発行された返金、配送料、および徴収された売上税。総額をクリアリング口座に貸方記入し、収入、配送料、および税金負債口座に借方記入します。あなたの損益計算書は、現在、1日ごとの収益を示しています。これは、税務準備と利益分析が必要とするすべてです。96件の孤立した請求書なしで。（収入および税金口座をゼロから設定する場合は、WooCommerce会計ガイドに完全な勘定科目表構造が記載されています。）

   
   
3. 
   

   *支払いが入金されたら、仕訳として記録します。* 支払いの総額をクリアリング口座に貸方記入します。純預金額を当座預金口座に借方記入します。手数料の差額を「マーチャント処理手数料」という費用口座に借方記入し、返金取消を収入に対して投稿します。週末の例を使用します：Stripe Clearingに7,200ドルを貸方記入し、当座預金に6,782.40ドルを借方記入し、手数料に237.60ドルを借方記入し、180ドルの返金を収益に対して記帳します。すべてのドルに場所ができました。

   
   
4. 
   

   *銀行フィードで預金と照合します。* 仕訳の銀行行は6,782.40ドルで、預金も6,782.40ドルなので、QuickBooksはワンクリックでそれらを照合します。この瞬間、全体の構造が報われます。照合は、調査ではなく確認になります。

   
   
5. 
   

   *クリアリング口座の残高を監視します。* ゲートウェイで輸送中の金額、つまり数日分の売上、それ以上の金額にならない程度に、その残高は変動するはずです。着実に増加する残高は、手数料または返金がどこかで記録されていないことを意味します。この単一の数値はあなたの早期警告システムであり、優れたCPAが最初に確認するものです。

   
   

[画像：フロー図 — 日次サマリーエントリがStripe Clearing口座に流れ込み、次に支払い仕訳が当座預金（純額）と処理手数料（費用）に分割され、最後に銀行フィードとの照合が行われる]

Done by hand, this takes a competent bookkeeper 30–60 minutes per gateway per week, and every step is a chance for a typo. But the structure is correct — and structure is the thing no order-syncing plugin gives you.

In LedgerPort, this architecture is a settings page

If those five steps sound like a lot of journal discipline, here’s the part worth knowing: in LedgerPort’s WooCommerce plugin, each component exists as configuration. The Payments tab of Sync Config auto-detects every payment gateway active on your store and assigns each one its own clearing account, with a default clearing account as the fallback for anything you haven’t configured. One clearing account per gateway isn’t journal gymnastics — it’s a dropdown per gateway.

Tax gets the same treatment: sales tax posts to a QuickBooks liability account you designate, and a rounding line item absorbs the cent-level differences between WooCommerce’s tax math and QuickBooks’ — the reconciliation papercut nobody warns you about. How orders post is one more dropdown: Sales Receipt for paid orders, Invoice when payment comes later, Estimate for quotes. And the taxonomy of sync methods is platform-general — the docs’ own guidance puts roughly 100+ orders a day as the point where per-order records stop being bookkeeping and start being sediment, which is exactly where daily summaries earn their keep.

None of this demands a configuration project, either. Per the docs’ own FAQ, every tab ships with sensible defaults — most stores can start syncing without touching Sync Config at all, and tighten the settings later as the books demand it.

---

プラグインで十分な場合とそうでない場合

Honest answer: sometimes the order-level tools are the right call.

An order-level sync plugin is probably enough if: you’re under roughly 100–200 orders a month and can eyeball the gaps; you run a single gateway with simple, infrequent refunds; or your business is invoice-driven — wholesale and B2B stores where payments genuinely tie to specific customer invoices. In that last case, per-order sync isn’t a bug, it’s the requirement, and a tool like MyWorks is built for exactly it.

You need the payout-aware layer if: you run multiple gateways (Stripe plus PayPal is where most stores cross the line); refunds and disputes are a weekly reality; your volume makes per-order entries unmanageable; or a CPA closes your books monthly and expects the bank feed to match. At that point, order data alone can’t produce reconcilable books — no matter how well it syncs.

If you’re leaning toward the payout-aware route, three practical objections tend to come up next:

“Will it handle my subscriptions?” LedgerPort syncs standard WooCommerce order and customer data, and subscription renewals arrive as regular orders when WooCommerce creates them — so recurring revenue flows through the same pipeline, nothing special to configure.

“What if a sync fails silently?” Real-time sync rides on WooCommerce webhooks, and WooCommerce retries failed deliveries automatically. If something still slips through, a Manual Sync page inside wp-admin pushes data on demand — you’re never waiting on support to re-send an order.

“Can I run several stores against one account?” Yes — each connected store counts as one connection against your plan’s limit, visible on the Connection page. The rest of the practical questions (HPOS compatibility, credential storage, required user roles) are answered in Getting Started with LedgerPort for WooCommerce.

The engineering bar a sync layer should clear

There’s one more evaluation axis, and it’s the one plugin listings never show: what the software does to your store when it connects — and when it leaves. LedgerPort’s provisioning is automatic and transactional. Connecting creates a read-only WooCommerce REST API key — it reads your store, it doesn’t write to it — and registers 13 named webhooks covering orders, products, variations, customers, and refunds. If any provisioning step fails midway, everything already completed is rolled back automatically, so your store is never left half-configured.

The rest of the security posture is equally checkable: credentials are stored AES-256-CBC-encrypted using your site’s own WordPress security keys, connecting requires the manage_woocommerce capability (Administrators and Shop Managers), and LedgerPort never touches webhooks you created yourself. Disconnecting is just as clean — it deletes exactly the API key and webhooks it created, your store and orders are untouched, and your mappings survive for reconnection. A botched first attempt costs nothing.

The same discipline shows up when a sync goes wrong. Failures aren’t a silent gap or a PHP notice — they’re a named taxonomy with documented fixes: an expired QuickBooks token (the docs’ own pick for the most common sync error), an unmapped product, a duplicate entry, a missing required field. Each error states its cause and its recovery path. That, more than any feature checkbox, is the real boundary of “a plugin is enough”: it ends where unrecoverable, invisible failure begins.

---

自動化された場合の様子

LedgerPort is built as that payout-aware layer, and it supports WooCommerce alongside Shopify. It connects to your store and your gateways, then runs the architecture above automatically: daily summaries posted to gateway clearing accounts, payout journals with fees broken out, deposits that match your bank feed to the penny. Setup takes about 15 minutes, and stores at meaningful volume report saving hours every week.

Here’s the entire WooCommerce setup, start to finish:

1. 
   

   Install the plugin. In your WordPress admin, go to Plugins » Add New Plugin, search for LedgerPort, click Install Now, then Activate. You’ll need HTTPS on your site and a LedgerPort account — the full install walkthrough covers both prerequisites.

   
   
2. 
   

   セットアップウィザードを実行します。 起動後、LedgerPort はウィザードをフルスクリーンオーバーレイとして自動的に開きます。Connect to LedgerPort をクリックして開始してください。

   
   
3. 
   

   接続を承認します。 app.ledgerport.com にリダイレクトされ、ログインし、接続するビジネスを選択して Authorize をクリックします。その後、WordPress 管理画面に直接戻ります。

   
   

4. プロビジョニングを実行します。 LedgerPort は読み取りアクセス権を持つ WooCommerce REST API キーを作成し、注文、返金、製品、顧客の Webhook を登録し、接続を確認します。いずれかのステップが失敗した場合、すべて自動的にロールバックされます。設定が不完全なストアは残りません。成功すると、LedgerPort ダッシュボードに接続された状態で表示されます。

そこから、すべてが wp-admin 内の LedgerPort メニューの下に表示されます - ダッシュボード、マッピング、手動同期、監査ログ - そのため、配管を確認するために WordPress を離れる必要はありません。また、前のセクションの決済口座構造は、個別の設定プロジェクトではなく、日次サマリー同期方法であり、5つのドロップダウンのうちの1つで、一度選択されます。

And when a webhook fails — because one will

Real-time sync rides on webhooks, and webhooks are honest about their nature: sooner or later, a delivery fails. The question most free plugins can’t answer is what happens next. Here the answer has layers. WooCommerce itself retries failed webhook deliveries automatically. Anything that still slips through doesn’t vanish — it surfaces as a per-record sync status, recoverable from the Manual Sync page inside wp-admin.

The workflow is checkbox selection, then Push Selected or Push All, then a live progress modal that shows each record land or fail — with a reason attached, not just a red icon. And the detail that makes catch-up after an outage safe: pushing is guaranteed not to duplicate. Already-synced records are skipped automatically, and re-pushing a failed record creates or updates the QuickBooks entry rather than posting it twice. “Select everything, push all” after a bad week can’t double-post revenue.

Two more facts from the FAQ that belong here: the plugin is fully compatible with WooCommerce’s High-Performance Order Storage with zero extra configuration, and — as covered above — WooCommerce Subscriptions renewals ride the same pipeline as regular orders. Historical backfill uses this same page, too, which means “we’ve been on spreadsheets all year” is an import, not a data-entry project: page through the year, push, watch the statuses turn green.

トレードオフは、率直に言って次のとおりです。LedgerPort は要約します。個々の顧客レコードを同期したり、QBO で在庫を管理したりしません。ビジネスで顧客ごとの請求書が必要な場合は、MyWorks のようなツールがより適しており、比較ではその点を正直に説明しています。

料金は無料から始まります - 月間 30 件の注文まで、1 ストア、オンデマンドの手動同期 - そのため、支払い前に実際の入金が照合されるのを確認できます。成長プランは月額 $25 からで、毎日の自動同期が含まれます。スケールプランは月額 $67 からで、リアルタイム同期に加え、この投稿で説明している入金ジャーナルと手数料処理が含まれます。有料プランにはすべて、14日間の無条件返金保証が付いています - トライアルではなく、全額返金、質問なし。

---

柔軟性の代償

WooCommerce に関する悲喜劇的な真実をここに示します。それは素晴らしいものであると同時に、帳簿を台無しにするものでもあります。

任意のゲートウェイ、任意のチェックアウトプラグイン、任意のサブスクリプション拡張機能、任意の地域別支払い方法を実行できます。そして、そのエコシステムはすべてをサポートします。その柔軟性こそが、あなたがプラットフォームを選択した真の理由です。しかしそれはまた、あなたの財務データが、同じ言語を話すことに同意したことのない 4 つまたは 5 つのシステムから発生し、会計レイヤーがそれらのすべての言語を受け継ぐことを意味します。

プラグインエコシステムは、構造というものはオープンエコシステムが強制しないものであるため、それをあなたのために構造化することはできません。したがって、構造は会計レイヤー、つまり決済口座、日次サマリー、手数料明細に存在する必要があります。これは、他のすべての柔軟性のために支払う税金であり、注文同期がそれを支払ってくれると期待するのをやめれば、公正な価格です。

オープニングからの1,400件の請求書は間違っていませんでした。それらは、あなたの銀行が決して尋ねなかった質問に答えていただけです。あなたの帳簿に正しい質問に答えてほしい場合は、WooCommerceストアをLedgerPortに接続してください — 無料プランでは最初の支払いまでカバーされ、入金が一致した瞬間に、アーキテクチャが機能していることがわかります。