diff --git a/bindings/java/doxygen/os_accounts.dox b/bindings/java/doxygen/os_accounts.dox
index 351e0e0aaf979aed5e6aca6deb2641176dbc74df..dd15fc6026dc94537411f00306047f2a901d6f17 100644
--- a/bindings/java/doxygen/os_accounts.dox
+++ b/bindings/java/doxygen/os_accounts.dox
@@ -64,13 +64,13 @@ We recommend that the OS account addresses or names that were parsed from the da
 There are three unique elements to creating and updating OS accounts when adding data to the case database:
 
 <ol>
-<li>When creating and updating OS accounts in the case database, you need to avoid some pitfalls involving doing a lot of work in a transaction. Why? For single-user cases, if you have created a org.sleuthkit.datamodel.SleuthkitCase.CaseDbTransaction, you should never call another database access method unless it allows you to pass in the CaseDbTransaction you are using. Otherwise, the method that you call will attempt to create its own transaction and because you already have the underlying SQLite case database locked, the called method will block forever waiting for a lock it cannot obtain. For a multi-user case, you will run the risk of attempting to create rows in the case database that would duplicate rows created by another user on another machine. In this scenario, uniqueness constraints will cause your entire transaction to fail and everything you have done up to that point will be rolled back and will have to be redone.
+<li>When creating and updating OS accounts in the case database, you need to avoid some pitfalls involving doing a lot of work in a transaction. Why? For single-user cases, if you have created a org.sleuthkit.datamodel.SleuthkitCase.CaseDbTransaction, you should never call another database access method unless it allows you to pass in the CaseDbTransaction you are using. Otherwise, the method that you call will attempt to create its own transaction and because you already have the underlying SQLite case database locked, the called method will block forever waiting for a lock it cannot obtain. For a multi-user case, you will run the risk of attempting to create OS accounts in the case database that would duplicate accounts created by another user on another machine. In this scenario, uniqueness constraints will cause your entire transaction to fail and everything you have done up to that point will be rolled back and will have to be redone.
 
 This means that if you want to use a CaseDbTransation to add a lot of files or artifacts associated with OS accounts, you'll need to:
 <ol type="a">
-<li>Pre-process the data to identify what OS accounts you need to find references to 
-<li>See if the OS Accounts already exist and update them, if appropriate, or make new ones
-<li>Start the transaction and add the files and artifacts with the refrences to the OS accounts
+<li>Pre-process the data to identify what OS accounts you need to create or look up 
+<li>Look up or create the OS accounts in individual transactions 
+<li>Start a new transaction and add the files or artifacts with the references to the OS accounts
 </ol>
 
 <li>You need to check if you have more information than what is already stored (e.g., maybe the realm name was unknown).