AppFolio vs Buildium, job for job

How this page was made

Packaging, then price

What is gated is a fact about the product. A price is a number that moves.

Every limit, in one list

What Tenant Office does not do.

Each line is the boundary recorded against that capability in our own manifest, quoted exactly. It is the same list our engineers work from.

• Role-scoped workspace access

  Anyone can set up a workspace on Free for up to 100 active units and 3 outside owners, with no card. Staff join by an invitation from an administrator inside their organization.

• Maintenance queue and accountability

  Vendor dispatch, outbound messages, and payments remain in existing processes. The workspace records them; it does not perform them. A dispatch is recorded from inside the work order and names the vendor, the scope agreed and a not-to-exceed amount, against a vendor whose required certificates are re-checked at that moment; it is append-only, and a wrong figure is corrected by withdrawing it with a stated reason and recording a new one. The database refuses to record a dispatch unless the payload itself asserts that no vendor was notified, and it never stores that assertion, so no row can later be read as evidence that anything was sent. The dispatch itself reaches no vendor and no money moves. Where a home carries owner terms, a not-to-exceed amount above the owner's approval limit needs an approved owner request on that work order, recorded by staff after the home's current owner was linked, and a pending request blocks dispatch at any amount; an owner decision is staff-recorded, and the owner is not contacted by this product. A vendor bill that names the work order is approved only while an active dispatch to that vendor covers it, after the closeout is accepted, and within the not-to-exceed amount across every approved bill for that vendor on the work order; a bill above it is recorded and flagged until a revised dispatch authorizes it. Separately, the transactional email outbox emails the assigned staff member and, when an email address is on file, the assigned vendor about assignment and status changes; a current resident when staff schedule maintenance at their own unit; and, where an organization turns escalation on, the responsible manager for the property and then its administrators about a work order not taken on in time or past its due date. Each is recorded as not sent until the email settings for this deployment are installed and the published privacy notice covers it, and none carries the scope or amount of a dispatch.

• Evidence-enforced closeout

  Closeout requires attached evidence uploaded by a maintenance-scoped role. It does not verify that the work itself met a standard. At least one evidence document must be an image the database still holds: image-ness is re-derived in SQL from the persisted content type and the persisted file name together, and a photo whose bytes have been requested for deletion stops counting. The upload path separately refuses a file whose leading bytes do not match the type it claims, so neither a rename nor an asserted content type gets through on its own. Other file types stay welcome alongside it. Progress status is not a way around the gate, because a work order cannot enter Completed except by arriving there with an accepted closeout, but the rule gates that transition and not stored rows, so work orders already marked Completed before the closeout lifecycle existed keep their status.

• Record photos and documents

  Attachments target four record types only: a property, a unit, a resident, or a work order. Staff upload from a browser, and a resident may attach a photo to their own service request and to nothing else. Photo capture hands the browser off to the device camera from a file input; there is no in-page capture surface and no installed application.

• Double-entry operating ledger

  Immutable journals, and a month cannot close until six named reviews are each completed by a named person with a written note. The note is a note, not an attached document. It is not a tax engine and does not file anything. Books partition by legal entity rather than by property: an organization keeps one book by default and may create further ledger entities, each holding its own instances of the system accounts, its own bank accounts and its own accounting periods, so two community associations held in one organization can be closed separately. Three limits go with that. Only the system accounts are instanced per entity; a custom account is created at the organization and stays usable from inside an entity book rather than being redirected into it, which is also why trust cash is attributed by property and not by entity. Journal numbering stays one organization-wide sequence, so an entity journal has gaps in it that belong to its neighbours, and the entity report discloses that rather than renumbering. And a property must join an entity before it posts: assignment is refused once the property carries a journal entry and is permanent once made, because a book that has already commingled can only be separated by a restatement and this product does not restate. A property SCOPE is a different thing and is unchanged. A trial balance carrying account codes, an income statement and a balance sheet can each be scoped to one property and each exports. A scoped report is a view of one book filtered to the entries stamped with that property; it is not a separate set of books, it is not an audited statement for a separate legal entity, and its journal numbering has gaps in it. That basis is written into the exported file itself, so a scoped statement forwarded to a lender or a board carries its own limit with it.

• Bank statement reconciliation

  Ranks candidate matches for a human to accept. There is no bank connection and no automatic matching. Candidates are drawn organization-wide rather than per property, so where one organization holds more than one association the match list is not confined to the association being reconciled. Statement lines are imported from a file you provide, matches may be many to one, and completion is refused until the database itself confirms that every line is matched and that opening plus activity equals closing. An administrator can reopen a completed reconciliation with a written reason, and the reopen keeps every match while the completion event retains the working papers as they stood at signature. Only the last reconciliation on a bank account can be reopened, and a reopen is refused outright while a closed accounting period covers the statement window until that month is reopened first, which returns its month-end checklist to pending. While a reconciliation is open, removing a statement line or replacing a match withdraws the row rather than deleting it: the row is kept with the reason, the person and the time recorded against it, and once withdrawn it can be neither edited nor removed. A month cannot be closed until every active operating bank account that had started reconciling by the month end carries a completed reconciliation whose statement window contains that month end, and that is checked again at the moment the month closes rather than only when the checklist item is ticked. It proves the month end falls inside one completed statement window; it does not prove an unbroken chain of statement windows before it.

• Resident receivables

  Charges, externally received receipts, credits, and aging. Receipts recorded here were paid elsewhere: this ledger executes no payment and moves no money. A receipt that did not clear is recorded as a returned payment, which reverses the subledger entry and its journal in one transaction and can carry a returned-item fee bound to the receipt it came from. A returned payment is never used to record a refund, because the money did arrive; a refund of an online payment is its own append-only entry under Online resident payments, and a refund of money received elsewhere is not recorded here.

• Vendor certificate registry

  Staff-reviewed evidence gating vendor assignment. A vendor company is emailed only that it was assigned a work order and when the status of that work order changes, only when an email address is on file for it, and only once transactional email is active. A person an administrator or manager invites from a vendor company signs in to the vendor portal with an emailed code and sees only the work currently assigned to that company in that organization, which they can accept or decline with their own name recorded; they never see a dispatch amount, its scope, rates, invoices or certificates, and removing their access signs them out while their earlier answers stay on record. The same certificate check runs again at the moment work is dispatched, so a certificate that lapsed after the vendor was assigned blocks the dispatch rather than passing unnoticed.

• Vendor accounts payable

  Records one balanced accrual per approved invoice. This is explicitly not a payment, and no remittance is sent. An optional two-person rule stops whoever entered, edited or submitted a bill at or above a set amount from approving it. A bill that names a work order is approved only against that work order's active dispatch ceiling and accepted closeout. A payment made outside the product, by check, by an ACH the operator sent from their own bank, or another way, can be recorded against an approved bill and posts the settling entry; recording one moves no money either. Vendors do not see or submit invoices here.

• Owner statement reporting

  Immutable statement releases, plus staff-entered records of a delivery an operator performed elsewhere and of what an owner said back. An invited owner signs in through the same sign-in and multi-factor authentication staff use and reads the statements released to them, downloading the exact PDF that was frozen at release; which statements they see is decided by the owner frozen onto each release at release time, never by who holds the home today. In that portal an owner can also acknowledge a statement released to them and ask a question or raise a dispute about it or one of its lines; those rows are marked as the owner's own, and every delivery, acknowledgement and dispute a staff member enters is still the operator's account, not the owner's act. A question or dispute is reviewed, then resolved with an outcome and a required closure note, which is the reply the owner reads in the portal; nothing is emailed to the owner when it is answered. A dispute a staff member recorded may instead be withdrawn. Resolving one changes nothing about the released statement, which stays immutable: an upheld dispute may name the later release carrying the correction, and naming none is itself a recorded state. A delivery or acknowledgement is corrected by a new superseding row with its reason, never by an edit. Any of these rows may cite an evidence document that already exists in the workspace, but none of them requires one. An owner is a record in their own right — a name, a contact email, a phone and a mailing address — that a home's owner terms are pointed at, so one person who owns nine homes is one owner and not nine, and portal access is keyed off that record rather than off a terms row. A home therefore needs its terms recorded before it can be given an owner at all. The approval limit, the reserve balance and the preferred vendor deliberately stay on the per-property terms row, because the same owner legitimately sets them differently at different homes, and nothing hoists them onto the owner. Single-family owner terms still load in one reviewed import rather than being set property by property, carrying the approval limit, the reserve balance, the preferred vendor and the access and warranty notes; there is no management fee and no remittance term among them. The contact email on the owner record is the address the portal invitation is issued to, through the same authentication provider that invites staff and residents. Besides that invitation, the only email this product sends an owner is a notice that a released statement is available in the portal, sent to the portal sign-in address once the statement's PDF is published and only while that access is active; it is recorded as not sent until the deployment's email settings are installed and the published privacy notice covers it. It attaches no statement and sends no reminder, and it is not written into the delivery rows here, which remain the operator's account of something they did through a channel of their own. The owner email carried by the terms import is a different field again and is not the invitation address.

• Resident portal

  Exact-identity invitations with multi-factor authentication over a minimized view of home, lease, balance, documents, and their own service requests. The records a resident creates are a service request, a photo attached to one and, where the operator has switched online payments on, their own payments, saved payment methods and autopay enrollment. Online payment runs in Stripe test mode only in this release, so no resident can pay real money through it yet.

• Resident messages and announcements

  Drafts are saved and external sends can be recorded. No provider delivers a message, so nothing here may be described as sent. A delivery can be requested against a saved notice and its state is retained as evidence, but the provider registry is empty and there is no way to add to it outside a migration, so a requested delivery reaches nobody and is reported as unconfigured rather than as a success; the only states this product may write about its own behaviour are queued and unknown, and neither is a send. Against a saved notice the workspace records one immutable, exportable row per resident stating how that resident was reached or why not, over an audience the database derives from current residents rather than one the browser supplies; a resident for whom the product holds no email and no phone is stamped as such, and a unit in scope with no current resident is its own row. A later follow-up is recorded against that coverage row rather than replacing it. The table refuses an outcome the contact record will not support, so an email touch cannot be claimed against a resident with no email, nor a call against one with no phone. Those rows are the account of the person who carried the notice. They assert nothing about receipt or reading, they cannot be retracted once written, and no message or announcement written here reaches a resident from this product. Separately, a resident who submitted a service request through the portal is emailed through the transactional email outbox when it is recorded, when its status changes and when it is marked completed, and a current resident is emailed when staff schedule maintenance at their own unit; those emails are recorded as not sent until the email settings for this deployment are installed and the published privacy notice covers them, and none of them carries an announcement. The resident portal invitation is issued by the authentication provider. The audience is drawn from residents, so an association homeowner who is not a resident is not in it.

• Inventory import and reconciliation

  A reviewed, controlled import of exports you provide. It is not a live synchronisation with another system and does not carry full history.

• Subscription billing

  Free, for up to 100 active units and 3 outside owners, needs no subscription. Manager starts when an administrator subscribes in Billing, using graduated active-unit pricing. Unit changes affect renewal; a change to the rate schedule requires advance notice and separate acceptance.

Sources

Every statement on this page, with the date and the link.

Grouped by company. Nothing above appears here in different words: these are the same records, rendered from the same store the page itself reads.

AppFolio, Buildium, Rent Manager and their product names are trademarks of their respective owners. Tenant Office is an independent product and is not affiliated with, endorsed by, or sponsored by any of them. This page reproduces no competitor interface and makes no feature-parity assertion.