The package path is your first tell

Personal WhatsApp lives at /data/data/com.whatsapp/databases/. Business lives at /data/data/com.whatsapp.w4b/databases/. Both can exist on the same device, side by side, with completely separate msgstore.db and wa.db files.

If your extraction only surfaced one of them, ask why. A small trader or reseller will often run personal chats on one number and the shop on another, both on the same phone. Two databases, two timelines, two sets of contacts. Parse only the one your tool defaulted to and you have half the picture.

Structures personal accounts don't generate

Open the Business msgstore.db and walk the schema. A Business account generates structure a personal install never touches.

Broadcast distribution is the first place investigators trip. Business accounts push promotional and transactional messages to broadcast lists, and that distribution is recorded in the database. Broadcast targets carry the @broadcast JID suffix, and the recipient mapping sits across the chat and message structures. In a fraud or unsolicited-marketing matter, that is a distribution map. It tells you who the account was pushing messages to at scale, which a normal one-to-one chat reconstruction never shows.

WhatsApp Channels leave their own trace. Channel identities use the @newsletter JID suffix. If the subject was running a Channel, those JIDs link the handset to that broadcast identity. A personal install that never touched Channels won't carry meaningful Channel data, but on a Business account it can help establish operational control of a public-facing channel.

You will also find label structure. Business lets the user tag chats (New customer, Pending payment, Paid, Order complete). Those labels and their chat mappings persist in the database in the label tables. A label like "Paid" against a contact thread is the subject's own annotation that a transaction settled. That is the account holder classifying their own conversations, which can carry real weight when you are trying to show intent or knowledge.

Linked devices each hold their own cache

This is the part people get wrong even on personal WhatsApp, and Business makes it worse.

WhatsApp multi-device gives every linked endpoint its own Signal Protocol session and its own local message store. A WhatsApp Web session on a desktop, the WhatsApp Business desktop app, a second linked phone, each maintains a local cache independent of the primary handset.

Practically, the seized phone is not the only copy. If the subject ran the Business account from a shop laptop through the desktop app, that laptop holds its own decrypted message history that does not depend on the phone being available. Same conversations, separately stored, sometimes with messages that were cleared on the phone but never cleared on the desktop endpoint.

So when you scope a seizure for a Business account, the question is not "do we have the phone." It is "how many endpoints were linked, and where are they." The Signal Protocol session state on the device (in the axolotl.db session store) records the companion sessions. That list is your map to the other evidence sources you should be requesting under the same warrant.

Media threading does not map the same

On personal WhatsApp, media reference rows in message_media point to files under /sdcard/Android/media/com.whatsapp/WhatsApp/Media/. Straightforward. The file path, the message row, and the chat all line up cleanly.

Business stores its media under the com.whatsapp.w4b tree instead, and the threading is messier because of catalog and quick-reply content. Product catalog images, quick-reply attachments, and broadcast media don't always thread back to a single conversation the way a normal image does. A catalog image can be referenced across many customer threads from one stored file.

If your parser was built around the personal media layout, it can either miss the Business media folder entirely or misattribute a shared catalog image to the wrong chat. Verify media attribution by hand: take the media row, resolve the file path, and confirm the file exists where the row says it does. Do not trust the threaded view until you have walked at least a sample of those references back to disk.

Deleted rows still behave like SQLite

None of the Business-specific structure changes the underlying recovery picture. Deleted messages drop out of the B-tree and sit in the freelist until reuse or a VACUUM. The -wal file still holds pre-commit state.

So pull msgstore.db, msgstore.db-wal, and msgstore.db-shm together, every time. The WAL on a Business account is arguably more valuable, because broadcast and label operations generate a lot of write activity, and pre-commit versions of those rows can survive in the log after the main table has moved on.

The takeaway

Before you write a single line of your BSA Section 63 certificate, confirm which WhatsApp you actually parsed. Note the package name (com.whatsapp versus com.whatsapp.w4b) in your documentation. List every linked-device session you found, because each one is a separate potential source you are choosing to pursue or not. And hash the Business databases separately from personal, because they are separate evidence objects even when they sit on the same handset.

Treat Business as a different application that happens to share a codebase. The schema is telling you there's more to collect. Read it.

If your current toolchain folds com.whatsapp.w4b into the same parser as personal and you suspect you're losing broadcast and label structure, that's worth a closer look. Secfore treats WhatsApp Business as its own supported application, separate from personal WhatsApp. Reach us at sales@secfore.com.