既然在ERP中，會計自身不設明細數量賬，只能依賴倉庫明細賬的查詢功能，而倉庫賬中確有其事，會計總賬模塊只好全接收了，其結果當然是，在會計系統中，這筆業務沒有“借：銀行存款貸：主營業務收入”的記錄，卻有“借；主營業務成本貸：庫存商品”的記錄，這一票貨毫無回報地說沒就沒了，其成本則混進其它已銷售商品的成本中，被掩蓋起來，這就是“管貨的也管明細賬，只向會計報總金額”的直接后果，可見，ERP的設計者連基本的會計常識都沒有，其思路是大有問題的！
正確的做法應當是，財務會計也同時開設庫存明細賬，依據多聯式原始憑證的“財務聯”記賬，進行數量與金額的雙重登記，并與倉管員的倉庫數量賬相互核對，通過在實物數量上的“賬賬相符”（如有差異，應可以解釋）來保證企業的資產完整。上述業務有兩種可能：
一、造假行為只局限于出貨環節。假銷售提貨單是直接交到倉庫去提貨的，屬盜竊行為，則會計手頭不可能有原始憑證的“財務聯”，在會計的庫存賬上當然沒有任何記錄。通過倉庫存貨賬與會計存貨賬的明細數量比對，就能鎖定這一筆有差異的業務，進而采取追查報案、完善單據識別手段等措施來“亡羊補牢”；
二、造假行為是系統性的，延伸到全套“多聯式原始憑證”，其“財務聯”也送到了會計手中，這就啟動了復式簿記的“資產保護機制”了：
如果是本期銷售本期收現，那么與之對應的銀行存款匯進了哪個賬號，或者誰經手收取了現金？
如果是沖銷已收的預收賬款，單據上指明的客戶在本公司賬上是否確有預收賬款余額？經手人是否得到該客戶的授權委托？
如果是賒銷，單據上指明的客戶是否通過了本公司的信用評估，從而可以將其欠款掛在應收賬款上？經手人是否得到該客戶的授權委托？
……
為該筆出貨配上對應科目的努力，也是尋求對這些問題解答的過程，加上與相關客戶的及時對賬溝通，很輕易地就能揭露舞弊行為，這就是復式簿記在企業對外交易中所發揮的，難以繞過去的“保護資產”的作用。
取消會計明細賬易導致賬賬不符
取消會計明細賬的另一嚴重后果是，ERP下的庫存明細賬與會計總賬不符。我們先來考察類似的例子，從銀行存款調節表的編制說起。它是從銀行對賬單和企業銀行存款賬開始的，這兩個余額可能不一致，因為同一筆款項會有一方已收、已付而另一方未收、未付，或某一方錯記、漏記和重記的情況。查清后，調節表為雙方分別補上已方未記的款項，改正單方錯記、漏記和重記的款項，直至兩個余額相等為止。這就說明，銀行與企業的兩套賬具有重迭性或相似性，但在一定時點上，兩者之間又可能存在差異。編制銀行存款調節表的過程，并不是去修改雙方的賬面記錄使其一致，而是要達到“差異可解釋”的狀態。
與此類似，倉庫存貨賬與會計庫存賬之間當然也有差異，原因至少有：
一、錯誤的業務處理。雙方難免會發生單方的錯記、漏記和重記
二、未達業務。會計和倉庫在相同業務的處理上存在著“時間差”，如在月末“貨已到，款未付”。倉庫是一定要記錄的；會計則由于發票等單據未到無法及時記錄。
三、主體差異。倉庫管理員的實物保管責任，是以他能夠控制的物理空間范圍為限的，如上鎖的庫房和堆場等。其中，除了企業自有的存貨，可能還有代管顧客未及提走的存貨，暫管尚未通過驗收的存貨等諸多情況，這都必須構成倉庫賬的內容；而在會計的存貨賬上，只記錄屬于會計主體所有權的存貨。兩者之間因統計口徑上的不同而形成“永久性差異”。
四、制度差別。由于制度規定不一致而引起的雙方差異也常發生，表現在：
1．會計上規定的原材料成本口徑不僅限于發票價格，可能還要加上其它費用；而倉庫對進貨金額的記錄只能依據發票價格，對于其它費用單據并不知情；
2．除了有數量也有金額的業務必須登記以外，會計還必須對只涉及金額不涉及數量的業務也加以記錄，如購貨進倉后又收到供應商退回的折扣金額，或因故補付給供應商的差價款等，這些業務金額都要調整相應的存貨成本；而倉庫只登記有實物進出的數量和金額，對上述業務無從得知，更不用說調整了；
3．“款已收，貨未付”的未達業務，在跨月時也有麻煩，會計核算要求當月必須結轉銷售成本，從而在帳上立即注銷相應的存貨，無論是否已經發貨；而從實物角度看，很可能這些存貨根本還沒有被提走，倉庫當然還保持著原有的記錄。
五、舞弊行為。往往單方反映在倉庫記錄上。
由此可見，倉庫和會計對于同一業務的記錄脫節，是極為正常的現象。甚至可以說，兩者一致只是偶然的，兩者不一致才是必然的。所以，最簡明的方法當然是，采用兩套賬分別記錄，然后定期核對和解釋差異。我們常說“賬賬相符，賬實相符”，所謂“賬實相符”，是指倉庫賬要與實物數量相符，所謂“賬賬相符”，是指會計賬與倉庫賬經過核對后，要達到“差異可以解釋”的狀態，如果有錯弊，要及時處理。
下表中，我們以A材料為例，列舉一些完全可能發生的，導致雙方賬面差異的業務分別在倉庫存貨賬與會計存貨賬中登記。請讀者觀察一下，從“故事開始時”的雙方完全一致，到“故事結束時”的分道揚鑣，差異是如何產生的。再試著設想，有什么格式能用一套賬來同時滿足兩家的要求，就可以體會ERP設計思想的荒唐了。
也許您會說，這些業務未必發生，也未必都發生在A材料上，好象哪壺不開偏提哪壺，故意找出來“抬杠”似的。確實是這樣的，在技術上，這叫“測試業務”，常用來檢查軟件設計是否潛伏著錯誤，通不過測試的，就是有缺陷的產品了。您的公司沒有發現不符，可能只是因為沒有發生這些業務，不代表軟件設計就沒有問題。
“一賬獨大”的實質，就是只考慮倉庫賬，而沒有考慮與之有差異的會計賬。但差異是客觀存的，其中，倉庫賬以保管責任為重，有實物數量為據，絕對不可更改；而會計賬須確保總體的借貸平衡，也輕易動不得，兩者間的差異是不可調和的，那么就和火山總要找到突破口一樣，兩者的差異，必然表現為庫存明細賬加起來不等于總賬。原因只在于，對于會計人員而言，總賬才是自己的，明細賬卻是“別人”的，怎能指望一定會互相吻合呢？而這一現象已使會計界蒙羞，專業聲譽嚴重受損！
