Sharing separates content from structure. Content — entries and annotations — is what the "Read and content" level unlocks. Structure — the category itself, its name, icon, colors, budget and its subcategories — always belongs to whoever shared it, at both access levels. And everything the guest writes inside the shared branch comes to belong to the owner, not to the guest.
A third family sits outside that split: the preferences of whoever is looking — where the shared category shows up in each person's tree, whether an annotation appears on their main screen, and each person's own alarms. None of that is structure or content: each one picks their own, and the choice never crosses to the other side.
Quick reference
| Inside the shared category, the guest can… | Read only | Read and content |
|---|---|---|
| See the category, the entries, the annotations and the budget | Yes | Yes |
| Use all of it in their own searches and totals | Yes | Yes |
| Create an entry | No | Yes |
| Edit or delete an entry, including the owner's | No | Yes |
| Create an annotation | No | Yes |
| Edit or delete an annotation, including the owner's | No | Yes |
| Tick list items, installments and the like | No | Yes |
| Rename the category, change its icon, colors or period | No | No |
| Create a subcategory | No | No |
| Delete the category or one of its subcategories | No | No |
| Place the shared category in their own tree and order it | Yes | Yes |
| Move the subcategories that came with it | No | No |
| Create or change the budget | No | No |
| Share the category with a third person | No | No |
Both columns apply to the whole branch: the permission is inherited by the shared category and by every subcategory under it.
Annotations
Can a guest with content access create an annotation in the shared category?
Yes, of any type — reminder, list, budget limit, pre-transaction, birthday. It is created inside the shared category and, on the next sync, is stored in the owner's account. From then on the owner sees it in their app as an annotation of their own, and the guest keeps seeing the same annotation because it comes back through the share delivery.
And delete an annotation?
Yes, and the deletion is real, not local. A guest with content access can delete any annotation in the shared branch, including the ones the owner created — inside the shared category the app does not distinguish who wrote what. On syncing, the annotation leaves the owner's account and disappears from their devices too. The app offers no way to undo that.
And editing, copying and moving?
- Editing — yes, with content access. Title, text, dates, amounts, items.
- Create a copy — yes. The copy stays in the same category and is likewise born belonging to the owner.
- Move to another category — only to a category of the guest's own, and the operation is a recreation: the app warns that "moving to another category will recreate the annotation in the destination category and remove the original". The result is that the guest ends up with an annotation of their own and the owner's original is deleted. Moving one in from outside the shared branch is not allowed.
What about an annotation's items — the shopping list, the installments?
They follow the annotation: whoever can edit the annotation can create, tick and delete its items; read-only guests cannot tick anything.
Does an alarm I set on a shared annotation ring on the other person's device?
No, in neither direction. An alarm is your own preference about when you want to be called, and it is not part of what sharing delivers. The owner can have an alarm on an annotation without the guest seeing anything, and a guest with content access can put their own alarms on the same annotation without the owner ever knowing. With read-only it is not possible: setting an alarm goes through saving the annotation, and saving is exactly what that level does not allow.
What the two do share is the annotation, so the text the notification shows is the same one: if the owner renames the annotation, the guest's alarm starts announcing the new name.
And main-screen visibility?
That is each person's own too. An annotation the owner keeps on their dashboard does not start showing on the guest's dashboard because of it, and vice versa. On accepting the share, the guest starts from the same choice the owner had made for that annotation; from there the two go their separate ways, and changing yours does not touch theirs.
Entries
Can a guest with content access create an entry?
Yes, straight into the shared category or into any subcategory of it. With read-only access, the shared category is not even listed among the categories when creating an entry.
What happens to an entry created by the guest after syncing?
This is the point that raises the most doubt, so here it is in detail:
- It goes up on the next sync, along with the rest of that device's changes.
- The server recognizes that it was born inside a shared branch and stores it in the owner's account. The entry comes to belong to the owner — no "guest copy" is kept on the server.
- The owner receives the entry on their own sync, as an entry of theirs, with nothing marking it as coming from someone else. There is no authorship field.
- The guest keeps seeing the entry, because it comes back through the same share delivery. While the share exists, both people see the same entry and it counts in both apps' totals — which is exactly the point of the "household expenses" case.
- If the share ends, the entry stays with the owner and leaves the guest's device. See "When the share ends", below.
And delete an entry?
Yes, with content access, including the ones the owner created. On syncing, the entry is erased from the owner's account and disappears from their devices.
Can the guest move an entry to another category?
No. While an entry sits in a shared category its category selector is locked — changing the category would take the entry out of the branch and leave stray copies on the other side. The lock applies to both sides: neither the guest nor the owner moves entries into or out of the shared branch.
And splitting an entry across categories?
The app refuses three splits:
- between the shared category and a category outside it;
- between categories from different shares;
- between a shared category and a category of one's own.
The reason is the same in all three: an entry is a single document, which the sync assigns whole to a single owner. A split crossing that boundary would arrive halved on the other side.
What if the guest posts in another currency?
It works. When the delivered content is in a currency the other side has never quoted, the sync brings the creator's exchange rates along, in both directions — so the totals convert without anyone having to type a rate.
The category's structure
Can a guest with content access change the shared category's name?
No, at neither level. On the guest's device the shared category offers no edit-category action, and on the manage-categories screen the attempt answers "Shared categories can't be edited". Even if the change were pushed, the server rejects any structural change coming from the guest and returns the owner's version, which replaces the local copy.
And the icon, the colors and the reference period?
Same as the name: they are fields of the category, that is, structure. The guest sees the icon and colors the owner chose, and they change on the guest's device when the owner changes them.
And the budget?
It cannot be changed. The owner's budget is delivered to the guest along with the category: they see the limit and the overspend warnings in their own app, with the same values. But creating or editing a budget is structure, and stays blocked at both access levels.
Can a guest with content access create a subcategory?
No. The add-subcategory action is not offered on a shared category, at neither level, and received categories are not listed as a possible parent when creating a new category either — there is no path in. The server rejects structure creation inside the shared branch, including a new category hung under it. Whoever needs one more level of detail asks the owner: the subcategory they create reaches the guest on the next sync, already with the same access level as the rest of the branch.
And delete a subcategory?
No. The attempt answers "Shared categories can't be deleted". This covers the shared category itself and every subcategory under it.
Can the guest move the shared category under one of their own?
Yes. The shared category arrives as a root category on the guest's device — even when it is a subcategory of something else on the owner's device — but they can drag it into any category of their own, and order it among its siblings. The choice is theirs alone: the owner keeps the category where it has always been and never learns about it. On the guest's other devices, the same arrangement shows up on the next sync.
The app refuses three destinations, saying why on screen:
- inside another category shared with them — its content would look like part of a share it has nothing to do with;
- inside a category they share with a third person — that person would see a branch nobody ever gave them;
- the subcategories that came with it do not move at all: only the shared category itself can be repositioned.
Reordering among siblings is never blocked, on either side.
What happens to that arrangement when the share ends?
It goes away. The preference is a separate record, kept on the device and on the server tagged with the share it came from. Once the share ends — revoked, deleted or declined — the record no longer describes anything: the server drops every record that came from that share right away, and the device drops its own in the post-sync cleanup, along with the rest of the branch.
Can I delete a category of mine that is holding a shared category?
Not while it is in there. The delete is recursive and would take the received category and the owner's content down with it, so the app blocks it and points at the way out: move the shared one elsewhere in your tree — or leave the share — and deleting works again.
Finding the person
Who can find me by phone?
Only someone who already has your number. A lookup is always one number at a time, needs a complete and exact number, and only finds you if you turned the option on under Sharing > Let others find me by phone. There is no listing, no search by name, and your number is never returned to anyone — what a lookup answers is the name and email of the account found, so the person inviting can check before sending.
Does PaNotas confirm the number is mine?
It depends on how the server is configured, and the screen itself tells you before you save: where confirmation is switched on, you get a code at the number you entered and have to type it there before the number is stored — a number that has been confirmed shows up marked as such.
Where it is not switched on, the number is stored as declared and nothing proves it belongs to whoever typed it. Either way, a number can only be on one account at a time (first to declare it keeps it) and the invitation still depends on your acceptance. If an invitation you weren't expecting shows up, decline it — nothing was shared until you accept.
Does turning this on publish my phone number?
No. It is not shown on any screen to other people, is not returned by searches, and is not used for anything else. Turning it off takes you out of the lookup immediately.
I couldn't find the person by phone. Why?
Either they don't use PaNotas yet, or they haven't turned the option on, or the number is on file in another form. Use the code invitation instead: it doesn't depend on knowing anything about their account.
Can an invitation code be used by more than one person?
No. The first to redeem it becomes the recipient, and from then on the code no longer works — anyone trying later is told the invitation was already used. That is why it should go to a person, not a group: whoever holds the code becomes the guest.
I sent the code to the wrong person. Now what?
Revoke the share before anyone redeems it — it appears in the list as "waiting for the code to be redeemed". If it was already redeemed, revoking works too: the access is removed and the other person's device cleans up on its next sync.
What if the person who got the code has no account?
The link opens a page explaining that sharing categories depends on a synced account, and offers to create one right there. After confirming the email and signing in, they come back to the invitation and answer it. If they'd rather decline, you find out — the share shows as declined on your side.
Does the code expire?
Yes, after 14 days. From then on it is no longer accepted and the screen shows "code expired" — just create another invitation. Each category may have up to three open invitations at a time.
Sharing onward
Can the guest share a category that was shared with them with someone else?
No, and the refusal happens in two places:
- On screen — categories received from someone else are not listed among the categories that can be shared, and the attempt answers "This category was shared with you and can't be re-shared."
- On the server — a share is only created when the category belongs to whoever asked. A request arriving by any other path is rejected, and the share record is removed from the guest's device on the next sync.
If two people need access to the same category, the owner is the one who creates both shares.
And a subcategory of the received branch, can that be shared?
No either: the restriction is inherited by the whole branch, not just by the category that was invited.
Who owns the data
Can the owner tell what the guest created?
No. Once synced, an entry or annotation created by the guest is indistinguishable from one created by the owner — there is no authorship field. What does exist is the symbol on the category card, which says that category is shared, not who wrote each item.
Can the guest see the owner's other categories?
No. Only the shared branch: the invited category, its subcategories and the content of both. Nothing above it and nothing beside it.
Does the shared content count in the guest's totals?
Yes. On the guest's device the received category is a category like any other — it shows on the dashboard, joins the searches, adds into the totals and the charts. The same expense shows in both people's totals, each in their own app.
When both edit at the same time
- The most recent version wins. When the guest's change arrives older than the version the owner already stored, the server returns the owner's version and it replaces the guest's local copy. There is no on-screen notice: the item simply shows the owner's content after syncing.
- Deleting is a change too and follows the same date rule: a deletion older than the other side's edit is undone.
- One exception is worth knowing: if the owner deletes an item while the guest edits that same item offline, the guest's edit recreates the item in the owner's account on syncing.
Sharing is not live editing. Every change — invitation, acceptance, new content, revocation — only exists for the other side after a sync on each side.
When the share ends
What happens to what the guest created?
It stays with the owner, because it has belonged to them since the very first sync. And it leaves the guest's device along with the rest of the shared branch, on the first sync after the end. The guest keeps no copy of anything — not even of what they posted themselves.
This is the same for all three possible endings: the owner revokes, the owner deletes the share, or the guest declines the invitation or leaves an accepted one.
Can the guest keep anything before leaving?
Only annotations, and only by moving each one to a category of their own — which recreates the annotation as theirs and removes the owner's original. Entries have no way: their category is locked precisely so they cannot leave the branch.
What if the owner wants to delete the shared category?
They cannot while the share is active: the deletion answers "Revoke the share before deleting it." The same protection blocks deleting a category above it in the tree.
Details that tend to surprise
- Switching the access level, in either direction, needs no new invitation: the new level applies on the server from the guest's next sync, and it is in that same sync that the branch is delivered to them again, with the editing buttons on their screen already adjusted. Anything the guest writes between your change and that sync is still rejected and undone on their device, like any change made out of turn — nothing here is instant.
- Two shares over the same branch: the most restrictive one always wins. If a category above was shared as read-only, the whole branch below it is read-only, even when another share grants content access.
- Inviting someone without an account works: they get an email inviting them to create one, and the share waits. It takes effect as soon as they create the account with that same email and accept.
- Older content arrives gradually, sync after sync, until the history is complete. The counts growing on the sharing screen are exactly that.
- Sharing requires the owner to have an account, the sync consent and a valid usage authorization (a subscription or a running trial). The screen tells you which of the three is missing.