The platform

Everything the office does, in one ledger

Not a general-purpose CRM with a synagogue skin. Aliyot, kiddush sponsorships, High Holiday seats, yahrzeits and membership tiers are first-class things here — because they were the first things built.

Contacts

Everyone your shul knows

A single record per household — the couple, their children, the names they are called to the Torah by, and the yahrzeits you need to remember.

  • Members and contacts are different things. A donor who comes twice a year is a contact; membership is a tier you grant deliberately, and it is what unlocks member pricing
  • Spouses get their own login. Two people, one household account, each with their own credentials
  • Aliases — the Hebrew name, the maiden name, the name on the cheque — all searchable, so a payment under any of them still finds the right person
  • Merge duplicates without losing a thing: pledges, payments and history all move across
  • Nothing is hard-deleted. Removing a contact hides them and keeps the audit trail
  • Import from the spreadsheet you already keep — contacts, opening balances and a year of transactions
portal.shulservices.com/admin
Dashboard
Contacts412
Outstanding$38,410
Received YTD$127,905
Credits$4,260
ContactTypeOutstandingCredit
Aaron & Devorah SteinMember$1,240.00$0.00
Miriam FeldmanMember$360.00$180.00
David RosenbaumContact$0.00$540.00
Yosef & Rivka AdlerMember$895.00$0.00

Illustrative data from the Beth Knesset demo congregation.

Pledges & payments

The part every other system gets wrong, because it was not designed for a shul.

Pledges that behave like obligations

Every pledge writes a matching charge into the ledger, and the two stay in lockstep for life. Change the pledge and the charge follows; correct the charge and the pledge follows. Cancel either and both are cancelled together.

  • Your own pledge types — every aliyah, hagbaa, opening the ark, whatever your shul calls them
  • Cancel is reversible; un-cancelling restores the charge and re-derives what is still owed
  • Editing an amount below what has already been paid settles the pledge; raising it re-opens it

Payments that allocate themselves

A member pays $500 against six outstanding pledges. The system pays the oldest first, splits the payment across as many as it covers, and leaves the correct remainder on the last one — and it still reads as one payment to the member.

  • Part-payments are first-class, not a workaround
  • Payments can be re-allocated later if they were applied to the wrong pledge
  • Card payments are locked from casual editing — refund or re-allocate instead

Account credit is a real balance, not a note in the margin

When someone overpays, or hands the office a cheque to draw down over the year, that money sits as account credit. The office can spend it against any pledge, ticket or fee from the same screen — and if the credit does not cover the amount, the system refuses rather than half-paying, because a partly-applied payment is far harder to unpick afterwards.

Transactions

One ledger, and it always balances

Every charge, payment, donation, ticket, refund and credit in one filterable list — with the standing of whoever you are looking at pinned to the top.

  • Filter by contact, date range, type, product, event or status, and combine them
  • Pick one contact and their outstanding, paid this year, unpaid pledges and credit appear above the table
  • Refund a card payment back to the card it came from, in full or in part
  • Email any transaction to the person it belongs to, straight from the row
  • Money received is one number with one definition, shared by every screen that shows it
portal.shulservices.com/admin/transactions
Standing for Aaron & Devorah Stein — all-time, not affected by the filters below
Total Outstanding$1,240
Total Paid YTD$3,780
Unpaid Pledges6
Account Credit$0
DateTypeDescriptionAmount
Aug 29ChargeMaftir — Shabbat$36.00
Aug 24PaymentCard ···4192$180.00
Aug 18Ticket2× Adult — Elul Shabbaton$80.00
Aug 11DonationOnline donation (website)$118.00
Aug 02RefundedKiddush sponsorship$250.00

The contact-standing summary above the ledger. Illustrative demo data.

Sponsorships

Kiddush & Seuda Shelishit

Open a date at a price you choose, and let it be taken — from a member's phone, from the office, or by a stranger on your public website.

  • Tiers you define, with a price that stays editable per date
  • Any date can be opened, not just the ones a developer thought of
  • Slots are held atomically before the card is charged, so two people cannot book the same Shabbat — and a declined card releases the hold
  • The price is always recomputed on the server; whatever the browser sends is ignored
Events & seats

Tickets, seats and the High Holidays

Events carry products; products carry prices. That is what makes the High Holidays a settings change rather than a development project.

  • Member and non-member pricing on the same ticket, applied from the buyer's record
  • Adults and children counted separately, with an optional hard capacity cap
  • High Holiday seats priced by tier — men's, women's, gold, whatever your shul sells
  • The office can sell a ticket at its own price, for the person who pays by cheque at the door
  • Buy on the website, buy in the portal — the same ledger row either way

An event, on sale, in four steps

No developer, no support ticket, no waiting for us. Somebody in the office does this between phone calls, and the website updates itself.

Create the event

Title, date, time, location, a paragraph of description. Tick show on the Holidays page if it is a festival rather than an ordinary event, and it files itself there instead.

About a minute.

Drop in a flyer

Upload the picture you already have. It appears on the card and opens full-size when a visitor clicks it, stored against your congregation alone.

Replacing it later overwrites the old one, so nothing is left orphaned behind.

Attach what people are buying

Adult ticket, child ticket, a sponsorship level, a reserved seat — each with its own price, and a separate member price where members pay less. Set a capacity if the room has a limit, or leave it open.

Seats are part of the product, so two adult tickets count as two seats without anyone doing sums.

Save — it is already live

The event is on your website immediately, with a working checkout. Every purchase lands in the ledger attributed to the buyer, and the office can still sell a ticket over the counter at whatever price it agrees.

No publish step, no deploy, no cache to clear.

bethknesset.shulservices.com/holidays
The Beth Knesset demo website Holidays page, showing cards for Rosh Hashanah, Yom Kippur and Sukkot with their flyers, dates, venues and descriptions.

Holidays on the demo congregation's site. Each card is an event created in the portal with its flyer — nobody edited a web page to put them there.

bethknesset.shulservices.com/events
The Beth Knesset demo website Events page, showing upcoming community events as cards with flyer images, dates, venues and descriptions.

The same events on the Events page — festivals filed to Holidays, everything else here.

The same is true of everything else on your site

Prayer times, classes and shiurim, holiday schedules and sponsorship prices are edited in the portal exactly the same way — typed once, live immediately. The demo congregation's class timetable went from an empty page to six shiurim in the time it takes to type them.

Not a mailing list with a donate button

Underneath, it is a double-sided ledger

Every obligation is a charge. Every payment is a payment. They net to a balance you can defend to a treasurer, an auditor, or a member on the phone — and every figure traces back to the row that produced it.

What "it balances" actually means here

  • Charges and payments are different things. A pledge, a membership fee and a seat all raise a charge; cash, cards, cheques and credit settle them
  • Donations are money in but balance-neutral, so a giver never looks like they overpaid something they were never billed for
  • Account credit is a real stored balance, separate from what is owed and spendable against any charge
  • A running balance down the statement, so a member can see how they arrived at today's figure
  • Money received nets off credit, so a deposit spent later is never counted as income twice
  • Every row is stamped with who created it, who changed it and in what role — cancellations included

One definition, everywhere

"Total paid this year" means exactly one thing, computed in exactly one place, and the member portal, the printed statement and the office ledger all call it. Three screens that quietly disagree is how a shul loses trust in its own numbers.

portal.shulservices.com/history
Account Statement — Miriam Feldman
Balance-$360.00
Paid YTD$1,845.00
Credit$180.00
DateDetailChargePaidBalance
Jul 04Maftir — Shabbat90.00-90.00
Jul 19Card ···419290.000.00
Aug 02Membership — Family450.00-450.00
Aug 09Cheque 2841270.00-180.00
Aug 16Donation — General Fund118.00-180.00
Aug 29Opening the Ark — Shabbat180.00-360.00

The donation is money received but leaves the balance untouched — it settles nothing, because nothing was billed for it.

A member's own statement. Illustrative demo figures.

📉

Outstanding, per person

What each contact owes from unpaid pledges, at any moment — and the total across the whole shul.

🔄

Re-allocation

A payment applied to the wrong pledge is moved, and both pledges recompute. Nothing is deleted to fix it.

↩️

Refunds that reverse cleanly

Money back to the original card, the charge reversed, the pledge re-opened, the seat released.

🧾

Everything reconciles

Website, office and member portal are one ledger. Nothing to tie out at month end, because nothing ever diverged.

Members pull their own statement, whenever they want it

The biggest drain on a shul office is answering "what do I owe?" and "can you send me last year's giving?" Both stop being your job.

📄

Their full history, on demand

Every pledge, payment, donation, ticket and refund since they joined, with a running balance — at 11pm, without asking anyone.

  • Filter to this month, this year or any range
  • Download as a spreadsheet for their own records
  • Or a branded printable statement carrying your logo and colours
📬

Receipts arrive by themselves

Every payment triggers a confirmation written for the kind of payment it was — a pledge settled, a ticket bought, a kiddush sponsored.

  • Itemised, so it is obvious what was paid for
  • Members can opt out if they would rather not receive them
  • Sent from your congregation's name, in your colours
🔗

Even without an account

Members who will never log in still get their statement by email, with a personalised link that opens on what they owe and lets them pay it.

  • No password and no signup
  • The link is signed and expires, and is checked against their phone number
  • The office can still send or print anything on their behalf

And the office can send them in bulk

Select everyone carrying a balance from the dashboard and send statements in one pass, watching the progress as they go. Each carries a pay-now link, so the replies come back as attributed payments overnight rather than as a stack of cheques to key in.

What your members see

Most of the office's work is answering "what do I owe?"

Members answer it themselves, at 11pm, on their phone — which is the only reason this pays for itself.

💳

Pay what they owe

Every outstanding pledge, with the option to pay one, some or all of it — by card or from account credit.

📜

Their whole history

A running balance they can follow, and a branded statement they can download without asking anyone.

🕍

Sponsor a kiddush

See genuinely open dates and take one, without a phone call to the office.

👤

Keep themselves current

Address, phone, children, yahrzeits. The office stops being a data-entry service.

And for the ones who will never log in

Some members will not create an account, ever. They get a personalised link in an emailed statement that opens straight onto what they owe and lets them pay it — no password, no account. The link is cryptographically signed, expires, and is confirmed against their phone number before anything is shown.

The rest of it

The unglamorous machinery that decides whether a system survives contact with a real office.

CapabilityWhat it means in practice
Membership billingMembership types and plans, recurring fees raised on schedule, and payments that settle them — kept separate from pledges so neither distorts the other.
InvoicingSend statements to everyone who owes, from the dashboard, with live progress as they go out. Recipients can pay from the email.
ReceiptsAn emailed confirmation for every payment, written for the type of payment it was — and members can opt out.
RolesAdministrator, member and pledger. One person can hold several, and switch which portal they are looking at without changing what they are permitted to do.
Access requestsSomeone asks for an account from your public site; an administrator approves or declines it in the portal.
Saved cardsMembers can keep a card on file for next time. Only the last four digits and the brand are ever stored here.
SettingsPledge types, occasions, payment methods, products, membership plans and sponsorship pricing — all yours to change, with concurrent edits merged rather than overwritten.
Several congregationsOne login can serve more than one shul, with the data walled off between them. Useful for a shared bookkeeper or an umbrella organisation.
Works on a phoneInstallable from the browser and built mobile-first, so the office is not chained to one desk during the week and members can pay from wherever they are. Nothing about the platform assumes a screen on Shabbat.

Best seen with your own data in it

We will load your membership list and a year of transactions into a private demo, and walk you through your own shul.