تفصیلی یونیک:زمانی که کدینگ حسابداری طراحی میشود به تفصیلیهایی برمیخوریم که در چندین زیرگروه حساب بصورت مشابه به کار میروند، مثلاٌ شرکت آلفا هم جزء مشتریانی میباشد که به او میفروشیم و در مقابل فروش باید پولی از آن بگیریم( حسابهای دریافتنی) هم در مقابل خرید از او چک میگیریم ( اسناد دریافتنی) هم چک او را به حساب میخوابانیم (اسناد در جریان وصول) هم پیگیر نقد شدن چک او میشویم و....
از این نمونه تفصیلیها به وفور دیده میشود، وجود این تفصیلیها جدا از اینکه کدینگ حساب¬های ما را شلوغ می¬کند و کاربر را در تشخیص آنها با مشکل مواجه میسازد، به دلیل پراکنده بودن و یکتا نبودن آنها، گزارشگیری بهینه و یکتا از تفصیلی را با مشکل مواجه میسازد.
فرض کنید جناب آقای علیرضا محمدی را یکبار در سیستم با کد 300123 یکبار با کد 600127 یک بار در سیستم به نام آقای محمدی یکبار با نام علی رضا محمدی یک بار با نام آقای محمدی و... به کار بردیم حال اگر بخواهیم از آقای علیرضا محمدی گزارش بگیریم که با چه حسابهایی درگیر بوده و گردش داشته است چه باید بکنیم؟ میبینید که به دلیل یکتا نبودن آنها در گزارشگیری دچار مشکل خواهیم شد. لذا وجود تفصیلی یونیک و منفک از درخت حسابها با کد یکتا جوابگوی نیاز ما برای حل این مشکل میباشد.
تفصیلی شناور:زمانی که تفصیلی یونیک میشود به دلیل همین یکتایی آن با تمام حسابها درگیر نخواهد بود و باید بصورت شناور با بعضی از حسابهای مربوط به آن در ارتباط باشد، مثلاٌ شرکت آلفا بصورت شناور هم با حسابهای دریافتنی هم با اسناد دریافتنی هم با اسناد در جریان وصول هم با اسناد واخواستی در ارتباط است. پس یونیک بودن و شناور بودن لازم و ملزوم یکدیگرند.